Разница в стоимости наковальни между Java и Bedrock

У Java и Bedrock не просто разные столы зачарования и торговые сделки с жителями — их наковальни на самом деле по-разному считают стоимость. Это не слух и не погрешность округления; это настоящее расхождение в самой формуле, подтверждённое по правилам обеих редакций в собственном вычислительном движке AnvilCalc.

Единственное реальное различие в формуле

Обе редакции рассчитывают стоимость операции на наковальне, беря каждое объединяемое зачарование и умножая количество уровней на множитель редкости этого зачарования. Расхождение в том, какое именно количество уровней:

• Java берёт плату за итоговый уровень зачарования. На каком бы уровне зачарование ни оказалось на итоговом предмете, именно за это вы платите — умноженное на множитель редкости — независимо от того, с какого уровня оно начиналось.
• Bedrock берёт плату только за прирост уровня. Он берёт итоговый уровень, вычитает уровень, который уже был у целевого предмета, и умножает именно эту разницу на множитель редкости. Если уровень не повысился, вы не платите за это зачарование ничего.

Разобранный пример: Острота I → III

Это самый наглядный способ увидеть разницу. Допустим, у вас есть меч, уже заколдованный Остротой III, и вы жертвуете книгой, на которой есть только Острота I — объединение, которое ничего не меняет в уровне Остроты меча, поскольку III уже выше, чем I.

• В Java: стоимость = итоговый уровень × множитель = 3 × 1 = 3 уровня. Вы платите за то, что на результате существует Острота III, даже если жертва ничего не повысила.
• В Bedrock: стоимость = (итоговый уровень − начальный уровень) × множитель = (3 − 3) × 1 = 0 уровней. Поскольку уровень Остроты меча на самом деле не повысился, Bedrock не берёт за это ничего.

Тот же меч, та же книга, то же объединение — 3 уровня в Java, бесплатно в Bedrock. Это и есть всё расхождение в одном примере, и именно поэтому последовательность объединений, которая выглядит вполне разумной в мире Bedrock, может оказаться заметно дороже, если планировать её так же в Java.

Другое отличие: штраф за несовместимое зачарование

Java и Bedrock также по-разному обращаются с отброшенным зачарованием. Если ваша жертва несёт зачарование, которое конфликтует с чем-то уже имеющимся на цели — скажем, книга с Небесной карой объединяется с мечом с Остротой — это конфликтующее зачарование просто отбрасывается в обеих редакциях (ни одна редакция не блокирует объединение полностью из-за конфликта). Но Java дополнительно добавляет фиксированный штраф +1 уровень за каждое отброшенное таким образом зачарование; Bedrock не добавляет ничего дополнительного за то же самое отброшенное зачарование. Это меньший по значению эффект, чем разница «итоговый уровень против прироста», но он накапливается вместе с ней за весь многошаговый план объединения.

Почему это важно при планировании сборки

Оба различия указывают в одну сторону: Java стабильно дороже для совершенно одинаковой последовательности объединений, потому что она берёт плату за результаты (итоговые уровни, отброшенные зачарования), а не за изменения (только прирост уровня, без платы за конфликт). Если вы планируете порядок объединения вручную, предположение, что более дешёвые числа Bedrock применимы и к Java, недооценит нужное количество уровней — и разрыв растёт с числом шагов и количеством конфликтующих зачарований. Предел «Слишком дорого!» в 39 уровней (см. Наковальня говорит «Слишком дорого») применяется одинаково к обеим редакциям на каждый шаг, так что план, который комфортно укладывается ниже предела в Bedrock, может оказаться прямо на границе — или за ней — в Java для абсолютно той же сборки.

Именно поэтому AnvilCalc спрашивает, в какой редакции вы играете, прежде чем искать порядок объединения: один и тот же целевой предмет и список зачарований может иметь разный самый дешёвый путь и разную итоговую стоимость чисто из-за того, какая формула применяется. См. Стратегию зачарования о штрафе за предыдущую работу, который применяется одинаково к обеим редакциям сверх этого.

Открыть калькулятор →

Часто задаваемые вопросы

Дешевле ли зачаровывать в Bedrock, чем в Java?

Именно для объединения на наковальне — да, в большинстве реалистичных случаев. Bedrock берёт плату только за реальный прирост уровня зачарования, тогда как Java берёт плату за весь итоговый уровень независимо от начальной точки. Java также добавляет фиксированный штраф +1 уровень за каждое несовместимое зачарование, отброшенное при объединении, чего Bedrock не делает.

Почему жертва Остротой I на предмет с Остротой III что-то стоит в Java?

Потому что Java оценивает итоговый уровень зачарования на результате, а не прирост. Меч в любом случае заканчивает объединение с Остротой III, так что Java берёт плату 3 × множитель редкости, даже если собственный уровень жертвы (I) был ниже, чем уже было у меча.

Действует ли в Bedrock тот же предел «Слишком дорого!» в 39 уровней, что и в Java?

Да — предел одинаковый, 39 уровней на операцию, в обеих редакциях. Различие полностью в том, как каждая редакция рассчитывает стоимость, которая сравнивается с этим пределом, а не в самом пределе.

Блокирует ли конфликтующее зачарование объединение на наковальне в любой из редакций?

Нет, ни в одной из редакций. Конфликтующее зачарование на вашей жертве просто отбрасывается, а не применяется; объединение всё равно проходит. Java сверху добавляет фиксированную плату +1 уровень за каждое отброшенное зачарование, тогда как Bedrock не берёт за это ничего дополнительного.

Почему AnvilCalc спрашивает, в какой редакции я играю, перед расчётом плана?

Потому что сама формула стоимости отличается, а не только доступные зачарования или версии. Один и тот же предмет, те же целевые зачарования и даже тот же порядок объединения могут дать разную итоговую стоимость опыта — а иногда и совершенно другой самый дешёвый порядок — в зависимости от того, применяется формула итогового уровня Java или формула прироста уровня Bedrock.