DEV Community: Zeldown

Nemesis: Behind the Scenes of Minecraft's Best Anti-Cheat

Zeldown — Sun, 13 Sep 2026 17:11:02 +0000

Paladium is one of the biggest Minecraft servers in France, running since 2015, with more than 700,000 unique players and up to 6,000 concurrent connections. Like any server that grows, we've had to deal with cheating at scale. Nemesis is our answer to that problem, built in-house rather than bought off the shelf. This article pops the hood and breaks down how it works.

Cheating on Minecraft

Minecraft trusts the client by default. When a player's game reports a position, the server just records it, without really asking whether that movement was even possible. Combat works the same way: the client says it hit someone, and the server applies the damage. Speed, reach, attack speed, all of it rests on whatever the client chooses to report.

And the game is written in Java, a language with no built-in security model. Its code can be opened and modified directly. You can also leave the files untouched and inject code into an already-running session instead. Or skip the game process entirely and run something external that reads what's happening and acts on the player's behalf.

Two ways to look at the problem

Anti-cheat boils down to two questions.

Is what the player is doing physically possible? The server continuously watches speed, reaction time, and precision, checking that all of it stays within what a human being can actually do.

Can the player's machine be trusted? We continuously check the integrity of the running game, to make sure no cheat is showing the player information they shouldn't have, even without touching a single movement.

Most servers don't have the ability to interact with the client the way we do. Paladium runs its own launcher, and that changes everything. So Nemesis can answer both questions, not just the first one.

From a simple mod to hardware

Cheating ranges from very simple to very advanced.

Modified client. The most common route: extra mods bolted on for an advantage, built with the exact same tools as any legitimate mod.
Injection. The game files on disk are never touched. A library gets loaded into an already-running session on the fly, the same injection technique used by perfectly legitimate mods.
Native cheats. Low-level code outside Java itself, wired into the game through the bridge Java provides for native code (JNI). Harder to write, and harder to catch with the usual Java-side detection tools.
External memory reading. A fully separate program that reads and writes the game's memory directly from outside, without ever running inside it, just like any regular user-mode application.
Kernel driver. The same idea, but from a system driver running with the same privileges as the OS itself, invisible to most conventional security software.
Dedicated hardware. A card physically plugged into the machine that reads memory straight off the bus, what's known as DMA, without ever executing a single line of code on the targeted computer.

The philosophy

One philosophy runs through all of Nemesis, server side and client side alike: block first, worry about punishment later. It plays out in stages. First, we try to stop the cheat from working at all: make the movement impossible, drop the packet, kill the effect rather than just flag it. If a cheat runs too deep to be cleanly blocked, the game closes instead of continuing to run in a state we can no longer vouch for. A sanction only comes as a last resort, once none of that was enough. The goal is to avoid punishing a player who was simply curious enough to try a public cheat found online, without doing anything specifically targeted at Paladium.

Our anti X-ray protection is a concrete example of this blocking philosophy on the server side. Normally, a player's game receives the data for every block around them all at once, including buried ones they can't see, ores included. An X-ray cheat just has to read that data the game already holds and show the hidden ore. With Nemesis, every ore in a chunk reaches the client disguised as plain stone, and the server only sends the real block once it actually becomes visible to the player's eyes. There's nothing for the cheat to read: the information doesn't exist on its end yet.

There's an extra technical wrinkle behind that. So latency doesn't create a visible lag the moment a block becomes visible, the server predicts ahead of time. It forecasts the player's trajectory and speed, lists every ore they could end up seeing, and sends it early into a secured zone of the client's memory. The switch from stone to ore then happens directly inside the game, at the right moment, with no perceptible delay. And on the security side, even if an X-ray cheat managed to dig through that zone, it would only ever see the ore right around that player, and only for a very short window.

Our autoclicker protection follows the same blocking logic, this time on the client side, for every click that counts in combat. A click isn't just counted or timed after the fact, it has to be proven the moment it happens. We identify the origin of that click at the lowest level possible, to tell a real move on the mouse apart from a click generated or injected by a script. That click then gets signed and tied precisely to the attack it triggers, before being sent to the server alongside the hit. For every hit landed, the server checks that this signature is valid and matches that exact attack. If it's missing, doesn't match, or arrives too late, the attack gets cancelled before it's even applied, the same way an impossible movement would be.

That signature only holds for that one click, on that one target, at that one instant. There's no way to precompute it ahead of time or replay it for a different hit.

What we watch on the server side

This part runs entirely server side, without asking anything of the client, and answers the first question from earlier: is what the player is doing physically possible?

The principle is simple. From every packet the player sends, the server builds a digital twin of their client and simulates it in parallel to check it's actually following the game's rules. This isn't just movement math, it's a real end-to-end simulation.

Concretely, it's an actual game running in parallel, minus the rendering. Ping, TPS (ticks per second), movement, interactions, all of it gets simulated. Think of it as a second server, with every player on it, continuously comparing each player to their own clone. This layer often acts as a safety net for whatever the client missed, but to keep false positives down, despite an already very low error rate, it still goes through manual review before a sanction in the vast majority of cases.

What we watch on the client side

That leaves the second question from earlier: can the player's machine be trusted? Here we're no longer just looking at the packets the game sends, we're looking at its actual state while it runs.

Going back to the spectrum from earlier, here's a simplified example for each level:

Modified client. Everything running inside the game should match something we know and expect. An unknown or modified mod on a player's machine is a signal.
Injection. We look at what's actually loaded into the game's process, not just what was launched at startup. Code that shows up after the fact, without going through normal loading, is a signal.
Native cheats. When the game talks to native code, we monitor that exchange. A call that has no business being there is a signal.
External memory reading. We keep an eye on who's reading the game's memory from outside. If an access doesn't legitimately come from the game itself, that's a signal.
Kernel driver / dedicated hardware (DMA). Kernel driver or a card physically plugged into the machine, same fight either way: whoever's behind it has full control over the memory the game runs in, which gives us plenty to detect anything touching it. That runs through several checks, including encrypted copies and integrity hashes that reveal at any moment whether a region was modified, or even simply read, try/catch blocks that react to the slightest suspicious access, and honeypots: zones deliberately exposed to trap anyone poking around.

These are deliberately simplified examples. In reality, Nemesis ships more than 40 distinct detection vectors, updated daily. And it's almost never black and white. Most of the time, a detection is a score built up from multiple signals, with hundreds of micro-factors feeding into each one.

How It Works

Everything we just described on the client side, the mods, the injection, the native calls, the memory, has to be checked by something reliable, something that can hold up to analysis over time. That's the job of a dedicated virtual machine.

In practice, it's not a single program running, it's a two-stage system. A primary VM, itself polymorphic, changes the moment the game launches and keeps evolving throughout the session through a stream of derivations. Its only job is to load and run a second VM, generated completely from scratch every time, that only the primary VM knows how to interpret. Once that second VM is in place, Nemesis's checks run as code packed inside what we call a stub, a small loader that's polymorphic too.

Before running any check, that stub re-verifies that the environment hasn't been compromised in the meantime. It then decrypts the real code, runs it, and immediately wipes it from memory, never leaving it in clear for more than a few milliseconds, before sending the result back to the server if needed.

To give a sense of the style, without showing the actual instructions (that part stays ours). None of this ever exists in clear text in reality. These are compiled instructions, never text you could read directly, and the instruction set itself changes on every execution. The example below is deliberately kept readable and commented to illustrate the logic, with made-up instruction names for the occasion:

; --- Primary VM ---
IMM    R0, secondary_vm_blob   ; puts the address of the secondary VM's encrypted blob into R0
SPAWN  R1, R0                  ; spins up a VM from that blob and hands off control to it

; --- Secondary VM (a different instruction set, unique to this VM) ---
UPK R2, R1                     ; unpacks the stub embedded in the received blob
XQT R2                         ; starts running the stub

; --- Stub ---
KFETCH R3, slot_a              ; fetches one key fragment, source 1
KFETCH R4, slot_b              ; fetches one key fragment, source 2
KFETCH R5, slot_c              ; fetches one key fragment, source 3
KFETCH R6, slot_d              ; fetches one key fragment, source 4
KFETCH R7, slot_e              ; fetches one key fragment, source 5
KMERGE  R8, R3, R4, R5, R6, R7 ; recombines the 5 fragments into a single key
DECRYPT R9, payload, R8        ; decrypts the real payload with that key
EXEC    R9                     ; runs the decrypted code
WIPE    R9                     ; immediately wipes the result from memory

All of this travels over our own communication protocol, which we call NemesisLink. At connection time, several key exchanges take place between the client and the server. From there, every message first gets encoded, then encrypted using a set of derivation keys computed from the actions actually performed in game. That means the key shifts with context, not just with time. The payload encryption itself runs on AES-GCM, executed directly through the CPU's hardware AES-NI instructions.

There's also a whole side dedicated to protecting Nemesis itself, not just to catching cheats. Multi-layered anti-debug, so nobody can attach a debugger and watch it run. Anti-VM, to spot when the game is running inside a virtual machine instead of a real one. And enumeration of external processes, to know what's running alongside the game and flag known analysis or cheat tools.

What we watch for duplicate accounts

A ban that gets wiped out just by making a new account is worthless. This section answers that exact question: how do you tell that two different accounts are actually the same player? Detection relies on a score that aggregates a large number of vectors, hardware and software, cross-referenced together rather than judged one by one.

On the hardware side, the idea is to tie a sanction to the machine, not just the account. There's first a real list of classic identifiers: the disk, the motherboard, and about a dozen other components in total. Nothing exotic, it's the kind of HWID most serious anti-cheats already use.

Then there's a more advanced layer, currently being tested with a subset of players, built on a real academic research concept: PUF (Physically Unclonable Function). Even two strictly identical components off the same production line are never perfectly identical at the physical level. Manufacturing tolerances create micro-variations that are invisible to the eye but measurable electrically. For RAM, that translates into two approaches known in the literature: measuring how long a memory cell naturally takes to decay once refreshing stops, or measuring micro-latencies in read and write access. In both cases, the result depends directly on the real electrical properties of that specific stick's transistors, impossible to reproduce elsewhere in software. Same logic applies to microphones. Every microphone has a slightly different frequency response, due to manufacturing tolerances in its membrane and capsule. By capturing a short audio sample and analyzing that response curve, you get a signature unique to that exact microphone unit, even against a strictly identical model off the same production line. In both cases, it's a fingerprint that doesn't change when you reinstall Windows or make a new account, it's literally etched into the hardware. RAM and microphones are only the visible tip of this research. Behind it, we're digging into the deepest workings of a machine, doing real research work, to invent identifiers that genuinely don't exist anywhere else.

Small fun fact: one of these tests ended up frying a graphics card, a dev card where that risk was expected and accepted going in. We test for real, under real conditions, on paths that are barely documented, if at all. That's exactly the kind of work that pushes Nemesis to the highest level it can reach. And to be clear, there was never the slightest risk to players in any of this: nothing like this ever reaches production before going through a whole series of test stages.

On the network side, we don't just compare two identical IP addresses. Correlation happens through geolocation and a probability score. Accounts that regularly connect from geographically consistent areas carry more weight in the score than a simple IP coincidence. We also detect non-residential IPs, typically VPNs or proxies used to mask a connection. And there's everything else stacked on top: an account's username and skin history, its creation date, whether it's already connected to other servers, and even playstyle itself, since the same player tends to keep their habits from one account to another. Taken individually, none of these signals is enough, but stacked together, they push the analysis a long way. An account that checks too many of these boxes gets automatically flagged, placed under watch, subjected to deeper manual analysis, and can end up under invisible restrictions or random tests, without ever knowing it.

We're confident enough in this system that we've actually turned off IP bans. We only sanction by hardware fingerprint now, which guarantees the best level of security without ever penalizing an entire household or a player who inherits an IP their provider reassigned.

From detection to sanction

This is the part players experience most directly, let's be honest about that. As covered above, the system blocks before it sanctions, and a detection doesn't ban anyone automatically by default. Before a vector earns the right to sanction without human involvement, it goes through a validation phase that can last several months: tuning, testing against real cases, long-term observation. The bar is strict, at least one full consecutive month without a single false positive before any automation. And nothing is set in stone. For maintenance, updates, and security reasons, detections get pulled, temporarily disabled, or added, on a schedule that isn't always predictable. The system changes almost every day without any of it showing on the outside.

The delay between detection and sanction ranges from near-instant to about 24 hours, depending on the severity of the case combined with a random factor. That randomness stops cheat developers from correlating the timing of a sanction with whatever triggered it. A fixed delay after the same type of action would tell them exactly what got caught. Near-instant sanctions are reserved for cases that pose a direct risk to other players' experience, for example a cheater about to kill or loot another player. In that case, protecting that other player in real time outweighs protection against correlation. The real condition is more complex than this simplified example: plenty of factors come into play to keep security intact regardless, but the goal is always to find the right balance.

The result: over more than a year of real-world use, a false positive rate close to zero. We're not claiming perfection, nobody honestly can. But at the slightest doubt, a case goes to human review instead of automation. It's slower, and we accept that trade-off. A wrongly banned player costs far more in trust than the time spent double-checking.

And if a sanction gets appealed, we don't just take our own word for it. Every detection log is kept, and anonymized. They preserve the technical context of the case, what triggered the detection and under what conditions, detached from the player's identity. When an appeal comes in, we pull the case back up entirely from those logs, replay what the system saw, and re-verify every step, with a human in charge. If the detection holds up, the sanction stands. If something's off, it gets reversed.

By the numbers

Over the last six months:

8,900 detections, across all vectors combined (several can involve the same player).
1,124 automatic sanctions, applied without human involvement.
2,020 total bans for cheating, since the system went live.
An average detection time of 193 seconds.

On the engineering side, across Nemesis as a whole: 1,500+ commits, for more than 57,000 lines of code in total.

What's next

The direction for what comes next: a program completely separate from the game itself, with a component running at kernel level, meaning the same privilege level as the OS. It's the path the most advanced anti-cheats on other games have taken (Vanguard at Riot, EasyAntiCheat, BattlEye), for a simple reason. At that level, you see the machine's real state without depending on what Windows or a user-mode program is willing to show you, and the component can be active before the game even launches.

A program separated from the game at that privilege level removes constraints that are inherent to any check running in the same process as whatever it's monitoring. Right now, this is a research and development effort. It won't push detection quality any higher, that's already where it needs to be. What it will mainly do is make the long-term engineering work simpler, built to last.

Transparency

We're publishing this article because trust is earned by showing the work, not by promising it, and Paladium's players have the right to understand, at least broadly, what's running on their machine. There's another reason too: very few projects at this depth get documented publicly, and we think the engineering behind Nemesis is worth sharing with anyone who cares about this kind of work, on Minecraft or elsewhere. We're proud of what we built. We believe Nemesis is, today, the best Minecraft anti-cheat out there. That's an opinion, and we own it. And we felt it was worth telling that story, even in part.

We don't intend to stop here. In the medium term, we plan to set up an external audit program: people outside Paladium who will come verify what we're claiming here, on a regular basis. In the long term, we're also thinking about opening more of this up to a wider audience. Nothing concrete to announce yet, just an intention: making this subject more accessible and more shared.

Thanks

Thanks to Paladium for the trust and for the opportunity to lead a project like this from day one.

This article isn't an incitement to cheat, nor a provocation aimed at anyone. We're simply documenting what we built, because we love this work and wanted to share it.

PatchNote du 08/06/2021

Zeldown — Tue, 08 Jun 2021 14:31:44 +0000

Bienvenue sur le PatchNote du mardi 08 juin 2021.

Ce mardi 08 juin à 14h30 (UTC+2), Paladium a effectué une petite mise à jour avec des corrections de bugs et des petits ajouts.
On vous en dit plus juste ici 👇

Home Finder

Correction d'une erreur avec le home finder

Mini Golem

Il était enfin temps😅

Les Mini Golems auront tous, y compris les anciens, un cooldown de 30 secondes lorsqu'ils seront posés.

Comme déjà expliqué, ce cooldown consiste à mettre le Golem en incapacité durant 30 secondes avant de devenir agressif, durant ce délai vous pouvez toutefois le tuer.

L'erreur venait à nouveau d'une erreur de NBT (voir derniers PatchNotes)

[-] public boolean isLoading;
[+] public boolean isLoading = true;

Grâce à cette modification, nous activons le cooldown par défaut et réglons le problème actuel.

Amulette du Chasseur

Il se peut que certains d'entre vous soient morts à cause du spawn inopiné d'un mob de l'Amulette du Chasseur 🙄

C'est pour cela que nous avons ajouté un message dans le chat lors du spawn d'un mob avec l'Amulette afin de vous alerter et vous laisser soit le temps de réagir soit de fuir 🤭 (chacun sa technique, on ne juge personne !).

/* On avertit le joueur */
player.addChatMessage(new ChatComponentText("§cUn mob de l'amulette de Hunter vient d'apparaître ! Fait attention à toi"));

/* On définit la position de l'entité */
ent.setPosition(entity.posX, entity.posY, entity.posZ);

/* On fait apparaître l'entité dans le monde du joueur */
world.spawnEntityInWorld(ent);

Désormais, plus d'excuse !

/serv

Fini de demander dans le chat sur quel serveur vous êtes !

Il vous suffit dès à présent d'effectuer tout simplement /serv et un message s’affichera dans le chat vous indiquant le nom du serveur sur lequel vous vous trouvez 🥰

/* Si le joueur est un joueur sur un proxy */
if(sender instanceof ProxiedPlayer) {
    /* On récupère ce joueur */
    ProxiedPlayer player = (ProxiedPlayer) sender;

    /* On envoie un message au joueur avec le nom du proxy */
    player.sendMessage("§eVous êtes sur le serveur §b" + player.getServer().getInfo().getName());
}

*plus d'informations [ici](https://www.spigotmc.org/wiki/creating-basic-command-functions-in-bungeecord/)*

VoidStone

Nous avons rajouté de nouveaux items pris en compte dans la Voidstone de minage 😇

Andesite
Diorite
Silex
Granite
Marbre
Pierre moussue
Limestone
Terre

Position de sa mort

Vous avez toujours rêvé de connaître la position de votre dernière mort ?! Aujourd'hui nous avons le plaisir de vous annoncer que c'est enfin possible 😱

Grâce à la commande /deathlocate disponible pour le grade Légende, vous pourrez connaître la position exacte du lieu où vous êtes mort pour la dernière fois.

*"Votre dernière mort se situe en: x:0 y:0 z:0"*

Pour cela nous sauvegardons votre mort

public void onDeath(PlayerDeathEvent e) {...}

Dans un fichier YAML (fichier de sauvegarde de Spigot) en savoir plus

Et ainsi vous pourrez la connaître même si le serveur crash 😄

GUI des métiers

Nous avons affiché le niveau du métier directement en-dessous de son icône dans le menu des métiers.

Son des coffres

Un coffre silencieux… mmh pas normal 🤔

Nous avons mis des sons d'ouverture et fermeture aux coffres suivants :

Titane
Améthyste
Paladium
Paladium Vert
Endium

pour cela rien de plus simple

this.worldObj.playSoundEffect(this.xCoord + 0.5D, (double) this.yCoord + 0.5D, this.zCoord + 0.5D, "random.chestopen", 0.5F, this.worldObj.rand.nextFloat() * 0.1F + 0.9F);

Et de même avec random.chestclosed pour la fermeture 🙃

Bug Report

Nous avons remis en jeu le /bugreport qui avait été désactivé à cause d'un souci majeur de déploiement 😶

Vous pouvez donc à nouveau nous signaler vos bugs les plus recherchés ^^

Pour en savoir plus, je vous redirige vers notre dernier PatchNote

Commandes en combat

Nous avons ajouté pleins de nouvelles commandes désormais utilisables en combat

/palalag time
/f enemy
/f neutral
/f ally
/f truce
/f create
/f leave
/f invite
/f promote
/f join
/f claim
/eat
/f f
/f list
/f map
/f map on
/f map off
/shop
/ah
/r
/msg

Encore une fois merci d'avoir lu ce document en espérant qu'il vous aura plu.

Nous attendons votre avis avec impatience en commentaire 🥰

this.setWriter("Zeldown");
this.setCorrection("calixtas");
this.setDevelopers("Zeldown");

PatchNote du 17/05/2021

Zeldown — Mon, 17 May 2021 17:05:31 +0000

Bienvenue sur le PatchNote du lundi 17 mai 2021.

Ce lundi 17 mai à 14h00 (UTC+2), Paladium a effectué une mise à jour intégrant diverses corrections de bugs ainsi qu'un outil de Rapport de Bug.

On vous en dit plus juste ici 👇

LuckyBlocks - Grade Légende

Pour rappel l'évènement "Endium Grade" des LuckyBlocks vous permet de recevoir un grade Légende et, si vous en possédez déjà un, un Endium Nugget vous est donné en contrepartie.

Seul souci, après le changement de version 6.5 -> 7, le nom des grades ont été modifiés, mais le changement de nom a été oublié dans le code de cet évènement ne donnant pas le grade à la personne ouvrant le LuckyBlock.

[-] lp user " + player.getCommandSenderName() + " group set Endium
[+] lp user " + player.getCommandSenderName() + " group set Legende

Obsi SlimePad Directionelles

Dans la dernière mise à jour, nous avions rajouté le fait de pouvoir choisir le sens des Slime Obsidiennes.

Suite à cet ajout un bug est survenu, il vous était possible de récupérer les slimepad générés avec l'obsidienne.

Nous tenons à vous rappeler que l'exploitation de tels bugs est interdite par le règlement et lourdement sanctionnée 🚨

Bouton "Passer" des LuckyBlocks

Lors de l'ouverture d'un LuckyBlock, un bouton "Passer" apparait, celui-ci permet de passer rapidement l'animation d'ouverture du LuckyBlock. Cependant lorsque vous cliquiez sur ce bouton, l'animation était bien interrompue mais l'évènement obtenu n'apparaissait pas au milieu de la roulette.

Le problème était dû à la gestion de la TimeLine des icônes déroulants, ceux-ci étant forcés à être terminés lors de l'appui sur le bouton.

/* 
on récupère l'icône correspondant à la colonne
et ligne souhaitées et on le force à finir son animation en 0 milliseconde 
*/
icons[row][cols].getTimeline().forceToEnd(0);

Sauf qu’après avoir forcé l'animation, le code réalisant l'animation était quand même appelé remettant l'animation à l'endroit d'avant le clic.

icons[row][cols].update();
icons[row][cols].draw();

Désormais, le code du clic est appelé après et les éléments ne sont updatés que si l'animation n'est pas passée.

if(!isPassed()) {
  // Si l'animation n'est pas passée
  icons[row][cols].update();
  icons[row][cols].draw();
}else {
  // Si l'animation est passée
  icons[row][cols].getTimeline().forceToEnd(0);
}

(ℹ️ plus d'information sur les boucles à 2 entrées en Java ici ℹ️)

Duplication avec les selles de Wither 😱

Lorsque vous montiez un Wither et que vous vous faisiez kick, la selle était drop au sol mais aussi redonnée dans votre inventaire. Désormais, nous vérifions si le joueur descend volontairement du Wither et donc s’il est accroupi à ce moment-là.

/* Lorsque l'on descend d'un Wither */
public void onDismountWither(EntityPlayer player) {
  // Si le joueur est accroupi
  if(player.isSneaking()) {
    //TODO donner la selle
  }
}

🗒️ Petite note sur le développement, il vous arrivera régulièrement dans le code de voir des mentions "TODO", celles-ci signifient en programmation une action à effectuer à titre informatif.

Cela évite de devoir écrire le code lorsque l'on explique ou simplement de noter que la partie n'a pas été encore faite mais de savoir ce qu'il faudra faire à ce moment-là 🗒️

Les dégâts des Boom Obsidiennes

Nous avons modifié le fonctionnement des dégâts des Boom Obsidiennes dans la dernière mise à jour, cependant lors de la modification de ceux-ci nous avions omis d'émettre les dégâts en ignorant l'armure du joueur.

Désormais leur explosion fera un nombre de dégât fixe comme défini durant le dernier PatchNote et en ignorant la protection du joueur.

[-] entity.attackEntityFrom(DamageSource.generic, damage);
[+] entity.attackEntityFrom(DamageSource.magic, damage);

Pour ce faire, nous avons modifié le type de dégât que nous appliquons au joueur. Plus d'infos sur les différents types de dégâts ici

Tentative Mini Golems

Nous avons à nouveau essayé de corriger le cooldown sur les anciens Mini Golems. Cependant cela est très compliqué de le tester pour nous car nous n'en possédons pas dans notre environnement de test. C'est pour cela que nous comptons sur vous et sur vos retours si le souci persiste grâce au nouveau système de Rapport expliqué par la suite 😇

Correction du crash avec les nouvelles enclumes

Lorsque vous essayiez d'utiliser une des nouvelles enclumes de Paladium, vous étiez kick du serveur.

Cela était dû à l'utilisation de mauvais packets pour l'ouverture du GUI, cela a été corrigé.

Chunk Loading - Optifine

La plupart d'entre vous connaissez le Chunk Loading d’Optifine, cette option ayant une possibilité de valeur MultiCore. Cependant lorsque vous l’activiez, vous aviez des problèmes de chargement de chunks vous permettant de voir à travers certains chunks.

Nous avons donc rajouté une sécurité en désactivant le bouton d'Optifine et en forçant sa valeur par défaut.

LuckyBlock - Extras

Vous ne nous l'aviez pas demandé 😄 mais nous avons pris la liberté de rajouter un petit "New" lorsque vous obtenez un évènement que vous n'avez jamais eu ainsi que une notification en jeu lorsque vous débloquez un nouveau palier dans le LuckyStats.

🎉 Nouveau système de Report de Bug 🎉

Sorti de nulle part, et car vous êtes tout aussi importants que nous pour faire évoluer Paladium, nous avons imaginé et développé un système de Rapport de Bug directement IG.

En effet, la nouvelle commande /bugreport est apparue en jeu. Lors de l'exécution de celle-ci, un menu sera ouvert occupant tout votre jeu (attention donc à ne pas entrer cette commande en moment de danger).

Dans ce menu vous aurez plusieurs champs :

Catégorie : ce bouton (cliquer dessus pour changer de catégorie) vous permet de sélectionner la catégorie du bug - si vous avez des suggestions d'autres catégories n'hésitez pas à nous le faire savoir sur le discord de Paladium en mentionnant Zeldown#9963 (tout abus sera sanctionné).
Titre : vous pourrez ici donner un titre à votre bug permettant facilement et rapidement de l'identifier et de le trier.
Description : ici vous avez champ libre pour décrire le bug avec le plus de détails possibles (liens de vidéo youtube et de screens sont autorisés et même conseillés)

Nous recevrons toutes les informations entrées mais aussi votre pseudo en jeu, votre serveur et la localisation (pas de souci, ces informations resteront privées) donc si vous rencontrez un problème à un endroit précis merci de vous y rendre pour activer la commande, cela nous aidera 😀

[BETA] Nous tenons à préciser que ce système est encore en béta, nous comptons sur vous pour nous faire vos retours dessus et nous aider à l'améliorer (un menu plus esthétique arrivera à l'avenir).

[RESTRICTION] Pour éviter des soucis nous avons mis un cooldown de 5 minutes entre chaque rapport, nous espérons que vous comprendrez.

[ATTENTION] Ce système ayant pour but de nous aider et de vous aider nous serons intransigeants sur les abus de rapports ainsi que les trolls et ils seront lourdement sanctionnés d'un bannissement de Paladium.

Encore une fois merci d'avoir lu ce document en espérant qu'il vous aura plu.

Nous attendons votre avis avec impatience en commentaire 🥰

this.setWriter("Zeldown");
this.setCorrection("calixtas");
this.setDevelopers("Zeldown", "Faustin");

PatchNote du 01/05/2021

Zeldown — Fri, 30 Apr 2021 22:17:58 +0000

Bienvenue sur le PatchNote du samedi 1 mai 2021.

Ce samedi 1 mai, Paladium a effectué une mise à jour axée sur des corrections de bugs ainsi qu'une légère modification de la mise à jour Pillage.

Trade

Vous n'êtes pas sans savoir que lors de la dernière maintenance le /trade a été ajouté aux personnes possédant un grade sur Paladium.

Cependant, certains bugs étaient encore présents :

Lors de l'annulation d'un échange en quittant le menu ou en se déconnectant, les items n'étaient pas bien redonnés aux joueurs participant à l'échange. Ceux-ci étaient jetés au sol, cela représentait donc un réel souci pour les joueurs réalisant un trade dans le spawn. Désormais, les items seront ajoutés dans l'inventaire si le joueur possède possède suffisamment de place et sinon seront jetés au sol.

/* lors de l'annulation */
public void cancel() {
    ...
    /* si l'on ne peut pas ajouter l'item à l'inventaire du joueur */
    if (!left.inventory.addItemStackToInventory(s)) {
        /* drop un item avec les paramètres : joueur, x, y, z, item */
        PlayerUtils.dropItemStack(left, left.posX, left.posY, left.posZ, s);
    }
}

Le trade contient un autocancel, c'est-à-dire que lorsqu'un joueur modifie le contenu de l'échange que l'autre joueur a validé, cela annule la validation pour éviter les arnaques. Cependant, nous avions oublié de prendre en compte les champs d'argent et d'exp. Cela a donc laissé place à quelques arnaques mais cela est désormais réglé.

Lors de l'envoi du packet (informations) au serveur lorsque l'on modifie notre état dans le trade CSButtonStateChanged.java une vérification de modification d'exp et de l'argent a été ajoutée.

if (tradeHasAccepted()) {
    setTradeHasAccepted(false);
    refresh();
}

Ce code permet, si une modification est faite alors qu’une partie du trade a validé l'échange, d’indiquer que la validation est annulée et de rafraichir le menu des deux participants.

Bug sous la bedrock

Différents bugs avaient lieu sous la bedrock. Ceux-ci permettaient notamment de rentrer dans des bases en passant par le vide (void) et d'utiliser certaines commandes pour pouvoir se retrouver dans une base. Les différentes mécaniques/bugs connus par notre équipe ont donc été corrigés. En voici la liste :

HangGlider sous la bedrock
Slimy Helmet sous la bedrock
Commandes de téléportation sous la bedrock (/tpa /tpaccept /tpahere /unsafetp) [liste non exhaustive]

Pour désactiver ces différentes mécaniques, l'ajout d'une simple condition en java a été suffisant.

if(player.posY < 0) {
    //annule
    return;
}

En effet, la condition est de vérifier si lors de l'utilisation de la mécanique visée le joueur se trouve en position Y inférieure à la couche 0. Si c'est le cas, alors la mécanique est annulée.

Boom Obsidienne

La Boom Obsidienne faisait des dégâts même dans des endroits où le joueur ne pouvait pas prendre de dégâts (exemple zone protégées ou serveur minage).

Cela était dû à une erreur de développement, le code effectuant une modification directe de la vie du joueur.

/* Définit la vie du joueur à sa vie -4 demi-coeurs (donc 2 coeurs) */
player.setHealth(player.getHealth - 4f);

Dorénavant, le code applique une attaque au joueur, permettant ainsi au jeu de vérifier s’il doit bien prendre des dégâts ou non.

/* Attaque le joueur de 4 demi-coeurs avec un type de dégât générique */
player.attackEntityFrom(DamageSource.generic, 4f);

Cela devrait régler ces différents soucis (PS: même en /god le staff prenait des dégâts 🚨)

Table d'enchantement moddée

Lorsque vous mettiez un item dans la table d'enchantement moddée, peu importe votre item la table vous proposait tous les enchantements possibles.

Désormais celle-ci se basera sur le type de l'item déposé afin de ne vous proposer que ceux disponibles et fonctionnels sur l'item.

/* lorsque l'on récupère la liste des enchantements avec un item */
public static Map<Enchantment, String> getEnchants(Item item) {
    Map<Enchantment, String> ench = new HashMap<>();
    /* On parcourt la liste des enchantements qui existe */
    for (Enchantment enchantment : enchants.keySet()) {
      /* Si l'enchantement peut être appliqué sur l'item en question */
      if (enchantment.type.canEnchantItem(item)) {
        /* On accepte l'enchantement */
        ench.put(enchantment, enchants.get(enchantment));
      }
    }
    /* On renvoie la liste des enchantements acceptés */
    return ench;
}

La table d'enchantement ne vous montrera donc plus que les enchantements disponibles, cela devrait vous faire gagner du temps.

Cobble Breaker

Récemment le shift click a été ajouté dans l'interface du Cobble Breaker, mais cet ajout a donné lieu à certains bugs notamment celui concernant la récupération d'expérience pour le métier de Mineur.

Dans certains cas particuliers, l'expérience donnée au joueur ne correspondait pas à la somme des particules récupérées.

Nous ne rentrerons pas dans les détails techniques de ce bug car il relève du code de Minecraft mais il est désormais résolu.

Réparation de la LuckySword

Contrairement à ce qui était prévu, il était impossible de réparer la LuckySword (palier 100 du LuckyStats) dans une enclume avec des LuckyBlock.

Il s’agissait juste d’un oubli des développeurs, le code a été ajouté et fonctionne désormais sur le serveur en espérant que certains d'entre vous la possède bientôt ! 🎉

HitBox

Il semblerait que les mobs du métier de Hunter ait une hitbox trop faible pour certains… Nous n'avons pas été radins et avons augmenté de 0,2 bloc l’intégralité des hitbox des animaux aussi bien en largeur qu’en longueur et en hauteur !

public class MyEntity {
   setSize(size + 0.2, size + 0.2, size + 0.2); 
}

Ce fut long et fastidieux... hum... hum...

Home Remover

Le Home Remover avait quelques soucis d'affichage, ceux-ci ont été réglés.

Le cooldown affiché au-dessus du Home Remover n'était pas toujours correct et descendait par paliers, nous en avons donc profité pour paramétrer le format du cooldown en HH:MM:SS.

return String.format("%02d:%02d:%02d", seconds / 3600, (seconds % 3600) / 60, seconds % 60);

Pour obtenir un cooldown de ce style nous allons d'abord récupérer l'heure : nombre_de_secondes / 3600

Ensuite pour les minutes, le calcul se complexifie un peu. Il faut savoir que en java les "%" sont ce que l'on appelle des modulo

Un modulo est le reste de la division, par exemple

10 modulo 3

Cela retournera 1, je m'explique: 3 rentre 3 fois dans 10, cela fait 9. La division n'étant pas parfaite il nous reste un "reste" qui ici est 1 (10-9).

Pour le nombre de minutes, nous allons donc faire (nombre_de_secondes % 3600) / 60

Et enfin pour le nombre de secondes : nombre_de_secondes % 60

Golem sous la bedrock

Il arrivait que certains Guardian Golem traversent la dernière couche de bedrock lorsqu'ils se trouvaient dessus. Le souci étant qu’une fois dans le void, ils tombaient à l'infini et donc ne remboursait pas la Guardian Stone au joueur maitre du Golem.

Désormais, si le golem se trouve en dessous de la couche 0, il sera automatiquement kill.

/* Lorsque l'entité se met à jour */
public void onEntityUpdate() {
    /* Si sa position est en-dessous de la couche 0 */
    if(this.posY < 0) {
        /* On tue le golem */
        setDead();
    }
}

Amulettes

Nous avons ajouté une petite description en-dessous des amulettes pour que vous ne soyez plus perdus (tout comme nous d'ailleurs).

Enchantement Humiliation

Nous avons pris la liberté et le plaisir de vous ajouter de nouvelles petites phrases pour accompagner votre mort avec l'enchantement Humiliation.

En voici quelques exemples :

Adieu , mort au combat sous la main de
n’est plus... l’a réduit en miettes

Nous vous laissons la surprise des autres 🙈

Modification Pillage

Modification de la Boom Obsidienne

Description : Génère une explosion qui affecte les joueurs et les entités

Dégâts entités : retire 10% de la vie de l’entité. Si l’entité a moins de 1% de sa vie initiale, il meurt.

Dégâts joueur passe de : 5 coeurs -> 2 coeurs

Pas de dégâts en-dessous de x coeurs passe de : 3 coeurs -> 2 coeurs

Rayon d’explosion : 1,5 bloc

Ajout d'un nouveau bloc : la Mega Boom Obsidienne

Basé sur la Boom Obsi, celle-ci fera trembler vos plus féroces ennemis

Description : Génère une explosion qui affecte les joueurs et les entités

Dégâts entités : Retire 20% de la vie de l’entité. Si l’entité a moins de 1% de sa vie initiale, il meurt.

Dégâts joueur : 4 coeurs

Pas de dégâts en dessous x coeurs : 2 coeurs

Rayon d’explosion : 2 blocs

Et voici son craft :

Obsidienne directionnelle

Ancien système : Actuellement les Slime Obsi se placent vers le joueur s’il est à 3 blocs ou moins. Sinon, elles se placent toujours vers le sud.

Nouveau système : Apparition d'un symbole sur la face sud de base. Ensuite, via la pioche en obsidienne (clic droit) le symbole se déplacera de face en face.
Si l’obsidienne est placée à côté d’une autre obsidienne, le symbole prend de base la même direction.

Ajout de 3 nouvelles enclumes

Désormais, le serveur compte des enclumes en Améthyste, en Titane et en Paladium !

| Enclume | Durabilité | Nombre moyen d'utilisation | | :--------------- |:---------------:| -----:| | Basique | 5 | 40 | | Améthyste | 7 | 56 | | Titane | 10 | 80 | | Paladium | 14 | 112 |

Les enclumes sont désormais utilisables dans les zones claims.

Aucune modifications n’a été faites sur la résistance des enclumes aux explosions et notamment à la dynamite. Cela reste comme avant, les nouvelles enclumes apportent donc seulement un plus grand nombre d’utilisation avant de se détruire.

Voici ce qui signe la fin de ce PatchNote, nous espérons que cela vous a plu et que ce nouvel aspect technique vous plaira tout autant.

Un sondage est disponible ici 🚀 ✨sondage✨

N'hésitez pas à laisser un commentaire ci-dessous, nous vous répondrons avec le plus grand plaisir.

PatchNote du 19/04/2021

Zeldown — Sun, 18 Apr 2021 22:05:03 +0000

Bienvenue sur le PatchNote du lundi 19 avril 2021.

Ce lundi 19 avril, Paladium a effectué une mise à jour axée sur la correction des bugs survenus durant la dernière maintenance :

Mini Golem Cooldown

Durant la précédente maintenance, nous avons ajouté un cooldown de 30 secondes sur les Mini Golems une fois posés. Cependant, après le déploiement de la mise à jour, nous nous sommes rendus compte que les Mini Golems craftés à l'aide d'une Guardian Stone datant d'avant la maintenance n'avaient pas ce temps d'attente.

En effet, celles-ci ayant un NBT (Named Binary Tag) plus ancien, elles n'avaient donc pas en mémoire ce temps de chargement et ne l'appliquaient pas une fois le golem apparu. Ceci est désormais corrigé.

Plus d'infos sur les NBT ici

Crash avec les Coordinates Jammer

Depuis leur arrivée sur le serveur, les Coordinates Jammers pouvaient faire crash tous les joueurs dans un rayon de 100 blocs s’ils étaient posés sur des Solid Airs ou d'autres blocs ayant un rendu particulier.

Ceci était dû à la tentative de ceux-ci d’adapter leur luminosité aux blocs voisins. Dorénavant, une série de conditions a été ajoutée afin que le jeu ne se ferme plus dans de telles circonstances.

Gain d'exp avec les Cobble Breakers

Durant la dernière mise à jour de Paladium, nous vous avons apporté la possibilité de récupérer les particules des Cobble Breakers à l'aide d'un Shift Click.
Cependant, nous avons oublié le fait de gagner de l'exp dans le métier de Mineur lors du Shift Click, ceci est désormais chose faite.

Alchimiste Table d'enchantement GUI

Durant la dernière mise à jour, nous avons apporté des modifications sur l'interface de la Table d'enchantement moddée.

Cependant, il persistait des soucis de z-index, c'est à dire, des éléments qui passaient les uns au-dessus des autres.

Ce problème est résolu.

Trade Shift Click

Depuis le 15 avril, nous avons donné accès au /trade aux personnes disposant d'un grade sur le serveur. Nous avons alors pris connaissance d'un souci lors de l'utilisation du Shift Click dans le trade.

En effet, si le joueur de droite durant l'échange utilisait la combinaison shift + click pour mettre un item dans le trade alors l'item essayait d'aller dans l'interface de gauche et disparaissait.

Ce problème est donc résolu temporairement en ayant désactivé l'action du Shift Click (désolé à tous ceux ayant perdu des items à cause de cela).

Trade Force Accept

Il était possible de forcer l'échange d'un trade en faisant /trade accept après avoir fait la demande d'échange à un joueur : cela acceptait automatiquement l'échange.

Désormais, seule la personne recevant la demande d'échange pourra /trade accept.

SuperMan sous la bedrock

Il était possible d'utiliser l'effet Superman sous la bedrock et ainsi sethome à travers la bedrock dans une base. Cela est dorénavant corrigé.

JetPack sous la bedrock

Il était possible d'utiliser le JetPack sous la bedrock et ainsi sethome à travers la bedrock dans une base. Cela est dorénavant corrigé.

Trade XP

Lors d'un échange d'experience durant un Trade, le nombre de niveaux n'était pas équivalent au nombre d'exp.

Si un joueur niveau 30 mettait "1 niveau", alors un joueur niveau 1 de l'autre côté du trade ne recevait qu’1 niveau, or cela correspond à bien plus d'expérience puisque les niveaux sont exponentiels.

Guardian Golem Health Bar

Lors de la mort d'un Guardian Golem, la barre de vie était toujours affichée. Cela était dû à un oubli de vérification dans le code de l'affichage de la barre de vie.

Cela est désormais ajouté.

if(BossStatusGuardian.guardian.isEntityAlive()) {...}

Ajout de chisel

Nous avions omis de vous l'annoncer durant la dernière maintenance mais le Chisel est de retour avec ses 35 familles !

Voici donc la liste des blocs vous permettant de crafter leurs nombreuses déclinaisons, nous vous laissons la surprise de leurs rendus 😜

Nous avons constaté que le dernier PatchNote vous a plu et nous espérons que vous apprécierez celui-ci tout autant.

N'hésitez pas à laisser un commentaire ci-dessous, nous vous répondrons avec le plus grand plaisir.

PatchNote du 15/04/2021

Zeldown — Tue, 13 Apr 2021 21:09:50 +0000

Bienvenue sur le PatchNote du jeudi 15 avril 2021.

Ce jeudi 15 avril, Paladium a effectué une mise à jour axée sur la correction de bugs plus au moins connus :

Bug Fertilized Dirt

Durant la maintenance du 5 avril 2021, un bug est apparu empêchant les joueurs au-dessus du niveau 5 Farmer de fabriquer de la Fertilized Dirt avec une Houe. Ce problème est désormais corrigé.

Clear des BackPacks

Depuis l'arrivée des Backpacks en début de V7 avec la refonte du métier Hunter, ceux-ci subissaient régulièrement des suppressions de leur contenu.

Ces suppressions survenaient lorsque le Backpack contenait un item ayant des enchantements. Nous avons donc modifié la façon dont leur contenu est sauvegardé afin de régler ce problème. Comme vous vous en doutez, nous ne pouvions pas modifier cela sans tenir compte des joueurs ayant actuellement un contenu dans leur Backpack. Ainsi un système de version pour les Backpacks a été mis en place automatiquement, et sera mis à jour dès l'actualisation des Backpacks de versions antérieures. Les derniers Backpacks qui contenaient un item enchanté seront donc clear comme avant et updatés à la nouvelle version afin que cela n'arrive plus.

Arnaque Capture Stone

Il était possible de capturer avec une Pierre de Capture des animaux renommés dans le but d'arnaquer. En effet, une fois un animal renommé capturé, la pierre affichait le nouveau nom dans sa description.

Désormais, le nom de l'item affichera le nom de l'entité modifié, mais la description restera adaptée au type de l'entité en elle-même et non plus à son nom.

Bug des Switch Arrows dans le vide

Suite à la correction du bug des Switch Arrows qui ne téléportaient pas le joueur après le tir de la flèche, il était possible de téléporter un Wither en étant sous la bedrock pour le faire se téléporter dans la base au-dessus de la bedrock.

if(base.posY > 0 && arrow.getPlayer().posY > 0) return;

Il est donc désormais impossible de téléporter n'importe quelle entité si vous ou elle se trouve en-dessous de la couche 0.

Modification du message de ban

Suite à la perte du forum durant l'incident du datacenter OVH de Strasbourg, les demandes de débanissement se font sur un discord de support dédié (PalaTicket), le message affiché lors d'un ban en jeu a donc été modifié pour prendre en compte ce changement de fonctionnement.

Crash du jeu

Ces derniers temps sur Paladium, de nombreux crashs du jeu sont apparus. Un certain nombre d'entre eux a été corrigé dont voici la liste :

Fermeture du jeu dans le menu d'un Grinder
Fermeture du jeu lorsqu’une touche de déplacement est assignée à un clic de souris
Fermeture du jeu lorsque l'on utilise un Slimy Helmet avec la touche de saut assignée à un clic de souris
Fermeture du jeu lorsque l'on tue un animal renommé avec un Endium Nametag
Fermeture du jeu lors de l'ouverture du /shop

Enchantement Solidité sur les Rings

Les Rings permettant de réparer des pièces d'armures ne tenaient pas compte de l'enchantement "Solidité", c’est désormais le cas.

Exemple : Big Ring: sans enchantement - Solidité 3

Item | Enchantement | Usage | |--|--|--| | Small Ring en Paladium | Aucun | 500 | | | Solidité 1| 933 | | | Solidité 2| 1437 | | | Solidité 3| 2093 | | Medium Ring en Paladium | Aucun | 1000 | | | Solidité 1| 2029 | | | Solidité 2| 2939 | | | Solidité 3| 3855 | | Big Ring en Paladium | Aucun | 3000 | | | Solidité 1| 5841 | | | Solidité 2| 9062 | | | Solidité 3| 11975 |

Golem infligeant des dégâts à travers les blocs

Un Guardian Golem pouvait mettre un coup à travers un mur s’il avait pris en chasse un joueur avant qu’un mur ne se trouve entre eux.

if(!golem.canEntityBeSeen(player)) {
    return false;
}

Désormais, le Golem devra obligatoirement voir le joueur pour pouvoir lui infliger des dégâts (et ceci malgré ses différentes améliorations).

Cobble Breakers

Il vous est désormais possible de faire un shift clic dans les slots d’un Cobble Breaker afin de récupérer vos particules plus rapidement.

HitBox des Serpents

En attendant une hitbox répondant parfaitement à la taille des serpents, leur HitBox a été augmentée.

**1x0.2 > 1.5x0.6**

Golems Farmers

L’IA des Guardian Golems en mode Farmer a été entièrement supprimée (100%). Désormais, ils ne se déplaceront plus même dans l'eau et ne sauteront plus sur place.
Ceci apporte une optimisation de 15% du jeu global dans une zone avec des golems.

Mini Golems

Suite à de nombreuses demandes des joueurs et un abus de la mécanique, une modification des Mini Golems a été apportée.

En effet, les Mini Golems étaient énormément utilisés durant des phases de combat afin de tuer l'adversaire instantanément à l'aide d'un Guardian Golem de niveau 80.

En attentant la refonte complète des Guardian Golems, nous avons pris la décision d'ajouter un délai sur les golems posés sous forme de Mini Golems :

Lors de l'apparition d'un Guardian Golem sous forme de Mini Golem, celui-ci ne pourra ni bouger ni attaquer durant une phase de chargement de 30 secondes, cependant vous pourrez l'attaquer et le tuer durant cette phase.

Chaudron / Alchimiste

Il n'est désormais plus possible de retirer une source d'Angelic Water dans un chaudron fonctionnel, qui avant permettait à l'aide d'un seau d'Angelic Water d'en obtenir 9.
Si vous retirez une source d'eau du chaudron, il se transformera automatiquement en lave et vous perdrez le Cauldron Core.

Glueball renderer

Lors du lancement d'une Glueball, son rendu en l'air n'était pas identique au rendu de la Glueball lancée par le joueur. Désormais le rendu de la Glueball dans les airs après son lancement sera identique à celle lancée.

Table d'enchantement / Alchimiste

Le design de la table d'enchantement du métier Alchimiste a été revu, il ressemble désormais plus à celui de Minecraft Vanilla tout en gardant son fonctionnement.
Les soucis de traduction ainsi que du chevauchement des éléments graphiques sont résolus.

Orthographe

Correction du nom des méduses.

**méduses > méduse**

Outils internes

Correction de certains outils utilisés par notre équipe de modération.

Ceci résume l'ensemble des bugs corrigés durant cette mise à jour, passons désormais aux ajouts étant prêts à être activés en jeu.

Le Trade

Le /trade a enfin fini d'être testé par les membres de notre staff ; sa version finalisée a donc été déployée sur le serveur de production durant cette maintenance et demandera encore 2 ou 3 tests en conditions réelles avant de vous être accessible. Lorsqu’il sera activé pour les joueurs, il s’agira d’un simple ajout de permission ne nécessitant donc pas une nouvelle maintenance.

Depuis la dernière fois que vous avez pu l’avoir entre vos mains, le trade bénéficie d’un nouvel ajout : si vous validez votre trade et que la personne en face de vous modifie le contenu de son échange, alors votre validation sera automatiquement annulée afin de vous laisser l’occasion d’approuver le nouveau contenu et donc éviter une arnaque éventuelle.

Les Boss

Suite à différents bugs et manquement d’optimisation, les boss n’avaient pas pu être ajoutés en jeu. Ils sont désormais 100% opérationnels et sans lag apparent, ils seront donc bientôt mis en place sans maintenance sur les serveurs.

Gare à vous… bien que le stuff qu'ils donnent puisse être attractif, faites attention de ne pas y laisser vos meilleurs équipements ! Durant les nombreux tests, ils ont appris à se défendre.

Ceci est la fin du patchnote du Jeudi 15 avril 2021.

On espère que ce nouveau design vous plaira, n'hésitez pas à nous faire des retours ci-dessous.