Java vs. Bedrock: A Bigorna Calcula o Custo de Forma Diferente

Java e Bedrock não têm só mesas de encantamento e comércios de aldeões diferentes — suas bigornas genuinamente calculam o custo de forma diferente. Isso não é um rumor nem uma diferença de arredondamento; é uma divergência real na própria fórmula, confirmada contra as regras-fonte das duas edições no próprio motor de cálculo do AnvilCalc.

A única diferença real de fórmula

As duas edições precificam uma operação de bigorna olhando para cada encantamento sendo combinado e multiplicando uma contagem de nível pelo multiplicador de raridade daquele encantamento. A divergência está em qual contagem de nível:

Java cobra pelo nível final do encantamento. Seja qual for o nível em que o encantamento termina no item resultante, é por isso que você paga — multiplicado pelo seu multiplicador de raridade — independentemente de em que nível ele começou.
Bedrock cobra só pelo aumento de nível. Ela pega o nível final, subtrai o nível que o alvo já tinha, e multiplica essa diferença pelo multiplicador de raridade. Se o nível não subiu, você não paga nada por aquele encantamento.

O exemplo resolvido de Afiação I → III

Essa é a forma mais clara de ver isso. Digamos que você tem uma espada já encantada com Afiação III, e você sacrifica um livro com apenas Afiação I — uma combinação que não muda nada no nível de Afiação da espada, já que III já é maior que I.

Na Java: custo = nível final × multiplicador = 3 × 1 = 3 níveis. Você paga pela Afiação III existir no resultado, mesmo que o sacrifício não tenha aumentado nada.
Na Bedrock: custo = (nível final − nível inicial) × multiplicador = (3 − 3) × 1 = 0 níveis. Como o nível de Afiação da espada não aumentou de fato, a Bedrock não cobra nada por isso.

A mesma espada, o mesmo livro, a mesma combinação — 3 níveis na Java, grátis na Bedrock. Essa é toda a divergência num único exemplo, e é por isso que uma sequência de combinações que parece perfeitamente razoável num mundo Bedrock pode ficar visivelmente mais cara se você planejá-la da mesma forma na Java.

A outra diferença: a penalidade de encantamento incompatível

Java e Bedrock também tratam de forma diferente um encantamento descartado. Se o seu sacrifício carrega um encantamento que conflita com algo já presente no alvo — digamos um livro de Julgamento combinado numa espada de Afiação — esse encantamento conflitante é simplesmente descartado nas duas edições (nenhuma das duas edições bloqueia a combinação completamente por causa de um conflito). Mas a Java adicionalmente acrescenta uma penalidade fixa de +1 nível para cada encantamento que descarta dessa forma; a Bedrock não adiciona nada extra pelo mesmo encantamento descartado. É um efeito menor que a diferença de nível-final-vs-aumento, mas ele se acumula junto com ela num plano de combinação de múltiplas etapas.

Por que isso importa para planejar uma build

As duas diferenças apontam na mesma direção: a Java é consistentemente a edição mais cara para exatamente a mesma sequência de combinações, porque ela cobra por resultados (níveis finais, encantamentos descartados) em vez de mudanças (só aumentos de nível, sem taxa de conflito). Se você está planejando uma ordem de combinação manualmente, assumir que os números mais baratos da Bedrock se aplicam à Java vai subestimar seus níveis — e a diferença fica maior quanto mais etapas e mais encantamentos conflitantes estiverem envolvidos. O teto de 39 níveis do "Muito caro!" (veja Muito Caro na Bigorna) se aplica de forma idêntica nas duas edições por etapa, então um plano que fica confortavelmente abaixo do teto na Bedrock pode ficar bem em cima — ou passar — desse limite na Java para a build idêntica.

É exatamente por isso que o AnvilCalc pergunta qual edição você está jogando antes de buscar uma ordem de combinação: o mesmo item alvo e lista de encantamentos pode ter um caminho mais barato diferente, e um custo total diferente, puramente por causa de qual fórmula se aplica. Veja Estratégia de Encantamento para a penalidade de trabalho anterior que se aplica de forma idêntica nas duas edições além dessa diferença.

Abrir a calculadora →

Perguntas frequentes

Encantar é mais barato na Bedrock do que na Java?

Para combinar na bigorna especificamente, sim, na maioria dos casos realistas. A Bedrock só cobra pelo aumento de nível que um encantamento realmente ganha, enquanto a Java cobra pelo seu nível final completo independentemente do ponto de partida. A Java também adiciona uma penalidade fixa de +1 nível para cada encantamento incompatível descartado durante uma combinação, o que a Bedrock não faz.

Por que sacrificar Afiação I num item com Afiação III custa alguma coisa na Java?

Porque a Java precifica o nível final do encantamento no resultado, não o aumento. A espada termina a combinação com Afiação III de qualquer forma, então a Java cobra 3 × o multiplicador de raridade mesmo que o nível do próprio sacrifício (I) fosse menor do que o que a espada já tinha.

A Bedrock tem o mesmo teto de 39 níveis do "Muito caro!" que a Java?

Sim — o teto é o mesmo, 39 níveis por operação, nas duas edições. A diferença está inteiramente em como cada edição calcula o custo que é comparado contra esse teto, não no teto em si.

Um encantamento conflitante bloqueia uma combinação na bigorna em alguma das edições?

Não, em nenhuma das duas edições. Um encantamento conflitante no seu sacrifício é simplesmente descartado em vez de aplicado; a combinação ainda acontece. A Java adiciona uma taxa fixa de +1 nível por encantamento descartado além disso, enquanto a Bedrock não cobra nada extra por isso.

Por que o AnvilCalc pergunta qual edição eu estou jogando antes de calcular um plano?

Porque a própria fórmula de custo é diferente, não só os encantamentos ou versões disponíveis. O mesmo item, os mesmos encantamentos alvo, e até a mesma ordem de combinação podem resultar num custo total de XP diferente — e às vezes numa ordem mais barata completamente diferente — dependendo de se a fórmula de nível-final da Java ou a fórmula de aumento-de-nível da Bedrock se aplica.