Java- vs. Bedrock-Amboss-Kostenunterschiede

Java und Bedrock haben nicht nur unterschiedliche Zaubertische und Dorfbewohner-Handel — ihre Ambosse berechnen die Kosten wirklich unterschiedlich. Das ist kein Gerücht und kein Rundungsfehler; es ist eine echte Abweichung in der Formel selbst, bestätigt gegen die Quellregeln beider Editionen in AnvilCalcs eigener Berechnungs-Engine.

Der eine echte Formel-Unterschied

Beide Editionen bepreisen eine Amboss-Operation, indem sie für jede zu verschmelzende Verzauberung eine Stufenzahl mit dem Seltenheitsmultiplikator dieser Verzauberung multiplizieren. Der Unterschied liegt darin, welche Stufenzahl das ist:

• Java bepreist die finale Stufe der Verzauberung. Auf welcher Stufe die Verzauberung am Ende auf dem resultierenden Objekt landet, dafür zahlst du — multipliziert mit ihrem Seltenheitsmultiplikator —, unabhängig davon, auf welcher Stufe sie begonnen hat.
• Bedrock bepreist nur den Stufenanstieg. Es nimmt die finale Stufe, zieht die Stufe ab, die das Ziel bereits hatte, und multipliziert diese Differenz mit dem Seltenheitsmultiplikator. Ist die Stufe nicht gestiegen, zahlst du für diese Verzauberung nichts.

Das durchgerechnete Beispiel Schärfe I → III

Das ist der klarste Weg, es zu sehen. Angenommen, du hast ein Schwert, das bereits mit Schärfe III verzaubert ist, und opferst ein Buch mit nur Schärfe I darauf — ein Merge, der an der Schärfe-Stufe des Schwerts nichts ändert, da III bereits höher ist als I.

• In Java: Kosten = finale Stufe × Multiplikator = 3 × 1 = 3 Stufen. Du zahlst dafür, dass Schärfe III auf dem Ergebnis vorhanden ist, obwohl das Opfer nichts erhöht hat.
• In Bedrock: Kosten = (finale Stufe − anfängliche Stufe) × Multiplikator = (3 − 3) × 1 = 0 Stufen. Da die Schärfe-Stufe des Schwerts tatsächlich nicht gestiegen ist, verlangt Bedrock dafür nichts.

Dasselbe Schwert, dasselbe Buch, derselbe Merge — 3 Stufen in Java, kostenlos in Bedrock. Das ist die ganze Abweichung in einem Beispiel, und genau deshalb kann eine Abfolge von Kombinationen, die auf einer Bedrock-Welt völlig vernünftig aussieht, merklich teurer werden, wenn du sie genauso auf Java planst.

Der andere Unterschied: die Strafe für inkompatible Verzauberungen

Java und Bedrock behandeln auch eine fallen gelassene Verzauberung unterschiedlich. Trägt dein Opfer eine Verzauberung, die mit etwas bereits auf dem Ziel in Konflikt steht — etwa ein Bann-Buch, das auf ein Schärfe-Schwert verschmolzen wird —, wird diese widersprüchliche Verzauberung in beiden Editionen einfach fallen gelassen (keine der beiden Editionen blockiert den Merge wegen eines Konflikts komplett). Aber Java schlägt zusätzlich eine feste Strafe von +1 Stufe für jede so fallen gelassene Verzauberung auf; Bedrock verlangt für dieselbe fallen gelassene Verzauberung nichts Zusätzliches. Das ist ein kleinerer Effekt als der Unterschied zwischen finaler Stufe und Anstieg, summiert sich aber über einen mehrstufigen Kombinationsplan hinweg mit ihm.

Warum das für die Build-Planung wichtig ist

Beide Unterschiede zeigen in dieselbe Richtung: Java ist für exakt dieselbe Abfolge von Kombinationen durchweg die teurere Edition, weil es für Ergebnisse bepreist (finale Stufen, fallen gelassene Verzauberungen) statt für Änderungen (nur Stufenanstiege, keine Konfliktgebühr). Wenn du eine Kombinationsreihenfolge von Hand planst, führt die Annahme, dass Bedrocks günstigere Zahlen auch für Java gelten, zu einem zu knappen Stufenbudget — und die Lücke wird größer, je mehr Schritte und je mehr widersprüchliche Verzauberungen beteiligt sind. Die 39-Stufen-"Zu teuer!"-Grenze (siehe Amboss zu teuer) gilt pro Schritt identisch für beide Editionen, sodass ein Plan, der auf Bedrock bequem unter der Grenze liegt, bei Java für denselben Build genau an — oder über — diese Obergrenze stoßen kann.

Genau deshalb fragt AnvilCalc, welche Edition du spielst, bevor es nach einer Kombinationsreihenfolge sucht: Dasselbe Zielobjekt und dieselbe Verzauberungsliste können rein wegen der geltenden Formel einen anderen günstigsten Pfad und andere Gesamtkosten haben. Siehe Verzauberungsstrategie für die Vorarbeitsstrafe, die zusätzlich dazu identisch für beide Editionen gilt.

Rechner öffnen →

Häufig gestellte Fragen

Ist Verzaubern auf Bedrock günstiger als auf Java?

Für das Kombinieren am Amboss speziell: ja, in den meisten realistischen Fällen. Bedrock bepreist nur den tatsächlichen Stufenanstieg einer Verzauberung, während Java ihre volle finale Stufe unabhängig vom Startpunkt bepreist. Java fügt außerdem eine feste Strafe von +1 Stufe für jede bei einem Merge fallen gelassene inkompatible Verzauberung hinzu, was Bedrock nicht tut.

Warum kostet es in Java etwas, Schärfe I auf ein Schärfe-III-Objekt zu opfern?

Weil Java die finale Stufe der Verzauberung auf dem Ergebnis bepreist, nicht den Anstieg. Das Schwert endet den Merge in jedem Fall mit Schärfe III, also verlangt Java 3 × den Seltenheitsmultiplikator, obwohl die eigene Stufe des Opfers (I) niedriger war als das, was das Schwert bereits hatte.

Hat Bedrock dieselbe 39-Stufen-"Zu teuer!"-Grenze wie Java?

Ja — die Grenze liegt bei beiden Editionen bei denselben 39 Stufen pro Operation. Der Unterschied liegt vollständig darin, wie jede Edition die Kosten berechnet, die mit dieser Grenze verglichen werden, nicht in der Grenze selbst.

Blockiert eine widersprüchliche Verzauberung in einer der beiden Editionen einen Amboss-Merge?

Nein, in keiner der beiden Editionen. Eine widersprüchliche Verzauberung auf deinem Opfer wird einfach fallen gelassen, statt angewendet zu werden; der Merge geht trotzdem durch. Java schlägt dafür zusätzlich eine feste Gebühr von +1 Stufe pro fallen gelassener Verzauberung auf, während Bedrock dafür nichts Zusätzliches verlangt.

Warum fragt AnvilCalc, welche Edition ich spiele, bevor es einen Plan berechnet?

Weil die Kostenformel selbst unterschiedlich ist, nicht nur die verfügbaren Verzauberungen oder Versionen. Dasselbe Objekt, dieselben Zielverzauberungen und sogar dieselbe Kombinationsreihenfolge können zu unterschiedlichen Gesamt-Erfahrungskosten führen — und manchmal zu einer völlig anderen günstigsten Reihenfolge —, je nachdem, ob Javas Finale-Stufe-Formel oder Bedrocks Stufenanstieg-Formel gilt.