Coût d'enclume : Java contre Bedrock

Java et Bedrock n'ont pas seulement des tables d'enchantement et des échanges de villageois différents — leurs enclumes calculent réellement le coût différemment. Ce n'est pas une rumeur ni une différence d'arrondi ; c'est une véritable divergence dans la formule elle-même, confirmée directement par rapport aux règles sources des deux éditions dans le propre moteur de calcul d'AnvilCalc.

L'unique vraie différence de formule

Les deux éditions tarifent une opération d'enclume en examinant chaque enchantement fusionné et en multipliant un nombre de niveaux par le multiplicateur de rareté de cet enchantement. La divergence porte sur quel nombre de niveaux :

Java tarife le niveau final de l'enchantement. Quel que soit le niveau auquel l'enchantement se retrouve sur l'objet résultant, c'est ce que vous payez — multiplié par son multiplicateur de rareté — indépendamment du niveau de départ.
Bedrock ne tarife que l'augmentation de niveau. Il prend le niveau final, soustrait le niveau que la cible avait déjà, et multiplie cette différence par le multiplicateur de rareté. Si le niveau n'a pas augmenté, vous ne payez rien pour cet enchantement.

L'exemple travaillé Tranchant I → III

C'est la façon la plus claire de voir cela. Disons que vous avez une épée déjà enchantée avec Tranchant III, et que vous sacrifiez un livre avec seulement Tranchant I — une fusion qui ne change rien au niveau de Tranchant de l'épée, puisque III est déjà supérieur à I.

En Java : coût = niveau final × multiplicateur = 3 × 1 = 3 niveaux. Vous payez pour l'existence de Tranchant III sur le résultat, même si le sacrifice n'a rien augmenté.
En Bedrock : coût = (niveau final − niveau initial) × multiplicateur = (3 − 3) × 1 = 0 niveau. Puisque le niveau de Tranchant de l'épée n'a en réalité pas augmenté, Bedrock ne facture rien pour lui.

Même épée, même livre, même fusion — 3 niveaux en Java, gratuit en Bedrock. C'est toute la divergence en un seul exemple, et c'est pourquoi une séquence de combinaisons qui paraît parfaitement raisonnable sur un monde Bedrock peut coûter sensiblement plus cher si vous la planifiez de la même façon sur Java.

L'autre différence : la pénalité d'enchantement incompatible

Java et Bedrock gèrent aussi différemment un enchantement supprimé. Si votre sacrifice porte un enchantement qui entre en conflit avec quelque chose déjà présent sur la cible — disons un livre Châtiment fusionné sur une épée Tranchant — cet enchantement conflictuel est simplement supprimé dans les deux éditions (aucune des deux éditions ne bloque la fusion purement et simplement en cas de conflit). Mais Java ajoute en plus une pénalité fixe de +1 niveau pour chaque enchantement qu'il supprime ainsi ; Bedrock n'ajoute rien de plus pour le même enchantement supprimé. C'est un effet plus petit que la différence niveau-final-contre-augmentation, mais il s'accumule avec elle sur un plan de combinaison en plusieurs étapes.

Pourquoi cela compte pour planifier une construction

Les deux différences pointent dans la même direction : Java est systématiquement l'édition la plus chère pour exactement la même séquence de combinaisons, parce qu'elle tarife les résultats (niveaux finaux, enchantements supprimés) plutôt que les changements (augmentations de niveau uniquement, aucun frais de conflit). Si vous planifiez un ordre de combinaison à la main, supposer que les chiffres plus bas de Bedrock s'appliquent à Java sous-estimera votre budget en niveaux — et l'écart s'agrandit avec le nombre d'étapes et d'enchantements conflictuels impliqués. Le plafond de 39 niveaux « Trop cher ! » (voir Enclume trop chère) s'applique de façon identique aux deux éditions par étape, donc un plan confortablement sous le plafond sur Bedrock peut se retrouver exactement au niveau — ou au-delà — de ce plafond en Java pour une construction identique.

C'est exactement pourquoi AnvilCalc vous demande quelle édition vous jouez avant de rechercher un ordre de combinaison : le même objet cible et la même liste d'enchantements peuvent avoir un chemin le moins cher différent, et un coût total différent, purement en raison de la formule qui s'applique. Voir Stratégie d'enchantement pour la pénalité de travail antérieur qui s'applique de façon identique aux deux éditions par-dessus cela.

Ouvrir le calculateur →

Questions fréquentes

Enchanter est-il moins cher sur Bedrock que sur Java ?

Pour la combinaison sur enclume spécifiquement, oui, dans la plupart des cas réalistes. Bedrock ne tarife que l'augmentation de niveau qu'un enchantement gagne réellement, tandis que Java tarife son niveau final complet indépendamment du point de départ. Java ajoute aussi une pénalité fixe de +1 niveau pour chaque enchantement incompatible supprimé pendant une fusion, ce que Bedrock ne fait pas.

Pourquoi sacrifier Tranchant I sur un objet Tranchant III coûte-t-il quelque chose en Java ?

Parce que Java tarife le niveau final de l'enchantement sur le résultat, pas l'augmentation. L'épée termine la fusion avec Tranchant III dans tous les cas, donc Java facture 3 × le multiplicateur de rareté même si le niveau du sacrifice (I) était inférieur à ce que l'épée avait déjà.

Bedrock a-t-il le même plafond de 39 niveaux "Trop cher !" que Java ?

Oui — le plafond est le même, 39 niveaux par opération, sur les deux éditions. La différence réside entièrement dans la façon dont chaque édition calcule le coût qui est comparé à ce plafond, pas dans le plafond lui-même.

Un enchantement conflictuel bloque-t-il une fusion sur enclume dans l'une ou l'autre édition ?

Non, dans aucune des deux éditions. Un enchantement conflictuel sur votre sacrifice est simplement supprimé plutôt qu'appliqué ; la fusion passe tout de même. Java ajoute une pénalité fixe de +1 niveau par enchantement supprimé en plus de cela, tandis que Bedrock ne facture rien de plus pour cela.

Pourquoi AnvilCalc demande-t-il quelle édition je joue avant de calculer un plan ?

Parce que la formule de coût elle-même est différente, pas seulement les enchantements ou versions disponibles. Le même objet, les mêmes enchantements cibles, et même le même ordre de combinaison peuvent ressortir avec un coût total en XP différent — et parfois un ordre le moins cher entièrement différent — selon que la formule au niveau final de Java ou la formule à l'augmentation de niveau de Bedrock s'applique.