Java versus Bedrock: aambeeldkosten

Java en Bedrock hebben niet alleen verschillende betoveringstafels en dorpelingenruil — hun aambeelden berekenen kosten echt anders. Dit is geen gerucht of een afrondingsverschil; het is een werkelijk verschil in de formule zelf, bevestigd tegen de brongedragsregels van beide edities in de eigen berekeningsengine van AnvilCalc.

Het ene echte formuleverschil

Beide edities prijzen een aambeeldbewerking door naar elke betovering te kijken die wordt samengevoegd en een niveauaantal te vermenigvuldigen met de zeldzaamheidsmultiplier van die betovering. Het verschil zit in welk niveauaantal:

• Java rekent voor het uiteindelijke niveau van de betovering. Op welk niveau de betovering ook uitkomt op het resulterende object, dat is wat je betaalt — vermenigvuldigd met zijn zeldzaamheidsmultiplier — ongeacht op welk niveau hij begon.
• Bedrock rekent alleen voor de niveaustijging. Het neemt het uiteindelijke niveau, trekt het niveau af dat het doel al had, en vermenigvuldigt dat verschil met de zeldzaamheidsmultiplier. Als het niveau niet is gestegen, betaal je niets voor die betovering.

Het uitgewerkte voorbeeld Scherpte I → III

Dit is de duidelijkste manier om het te zien. Stel dat je al een zwaard hebt betoverd met Scherpte III, en je offert een boek met alleen Scherpte I erop — een samenvoeging die niets doet met het Scherpte-niveau van het zwaard, omdat III al hoger is dan I.

• In Java: kosten = uiteindelijk niveau × multiplier = 3 × 1 = 3 niveaus. Je betaalt voor het bestaan van Scherpte III op het resultaat, ook al heeft het offer niets verhoogd.
• In Bedrock: kosten = (uiteindelijk niveau − oorspronkelijk niveau) × multiplier = (3 − 3) × 1 = 0 niveaus. Omdat het Scherpte-niveau van het zwaard niet daadwerkelijk is gestegen, rekent Bedrock er niets voor.

Hetzelfde zwaard, hetzelfde boek, dezelfde samenvoeging — 3 niveaus in Java, gratis in Bedrock. Dat is het hele verschil in één voorbeeld, en het is waarom een reeks samenvoegingen die er op een Bedrock-wereld volkomen redelijk uitziet, merkbaar duurder kan uitvallen als je het op dezelfde manier plant op Java.

Het andere verschil: de straf voor onverenigbare betoveringen

Java en Bedrock behandelen ook een afgevallen betovering verschillend. Als je offer een betovering draagt die botst met iets dat al op het doel staat — zeg een Kastijding-boek samengevoegd op een Scherpte-zwaard — wordt die conflicterende betovering in beide edities gewoon laten vallen (geen van beide edities blokkeert de samenvoeging volledig vanwege een conflict). Maar Java tikt daarnaast een vaste straf van +1 niveau bij voor elke betovering die het op deze manier laat vallen; Bedrock voegt niets extra toe voor diezelfde afgevallen betovering. Het is een kleiner effect dan het verschil tussen eindniveau en stijging, maar het stapelt op met dat verschil over een meerstaps combinatieplan.

Waarom dit belangrijk is voor het plannen van een build

Beide verschillen wijzen dezelfde richting op: Java is consequent de duurdere editie voor exact dezelfde reeks samenvoegingen, omdat het rekent voor resultaten (eindniveaus, afgevallen betoveringen) in plaats van veranderingen (alleen niveaustijgingen, geen conflictkosten). Als je handmatig een combinatievolgorde plant, zal ervan uitgaan dat de goedkopere getallen van Bedrock ook voor Java gelden je niveaus onderbudgetteren — en de kloof wordt groter naarmate er meer stappen en meer conflicterende betoveringen bij betrokken zijn. De plafondlimiet van 39 niveaus "Te duur!" (zie Aambeeld te duur) geldt identiek voor beide edities per stap, dus een plan dat comfortabel onder het plafond blijft op Bedrock kan precies op — of voorbij — dat plafond uitkomen op Java voor exact dezelfde build.

Dit is precies waarom AnvilCalc vraagt welke editie je speelt voordat het naar een combinatievolgorde zoekt: hetzelfde doelobject en dezelfde betoveringslijst kunnen een ander goedkoopste pad hebben, en andere totale kosten, puur omdat welke formule van toepassing is. Zie Betoveringsstrategie voor de straf voor eerder werk, die identiek voor beide edities geldt naast dit verschil.

Open de calculator →

Veelgestelde vragen

Is betoveren goedkoper op Bedrock dan op Java?

Voor aambeeldsamenvoegen specifiek, ja, in de meeste realistische gevallen. Bedrock rekent alleen voor de niveaustijging die een betovering daadwerkelijk krijgt, terwijl Java rekent voor het volledige eindniveau ongeacht het startpunt. Java voegt ook een vaste straf van +1 niveau toe voor elke onverenigbare betovering die tijdens een samenvoeging wordt laten vallen, iets wat Bedrock niet doet.

Waarom kost het offeren van Scherpte I op een Scherpte III-object iets in Java?

Omdat Java het uiteindelijke niveau van de betovering op het resultaat prijst, niet de stijging. Het zwaard eindigt de samenvoeging in beide gevallen met Scherpte III, dus Java rekent 3 × de zeldzaamheidsmultiplier, ook al was het eigen niveau van het offer (I) lager dan wat het zwaard al had.

Heeft Bedrock dezelfde plafondlimiet van 39 niveaus "Te duur!" als Java?

Ja — het plafond is dezelfde 39 niveaus per bewerking op beide edities. Het verschil zit volledig in hoe elke editie de kosten berekent die tegen dat plafond worden afgezet, niet in het plafond zelf.

Blokkeert een conflicterende betovering een aambeeldsamenvoeging in een van beide edities?

Nee, in geen van beide edities. Een conflicterende betovering op je offer wordt gewoon laten vallen in plaats van toegepast; de samenvoeging gaat nog steeds door. Java tikt daarbovenop een vaste kost van +1 niveau per afgevallen betovering bij, terwijl Bedrock er niets extra voor rekent.

Waarom vraagt AnvilCalc welke editie ik speel voordat het een plan berekent?

Omdat de kostenformule zelf verschilt, niet alleen de beschikbare betoveringen of versies. Hetzelfde object, dezelfde doelbetoveringen, en zelfs dezelfde combinatievolgorde kunnen uitkomen op andere totale ervaringskosten — en soms een heel andere goedkoopste volgorde — afhankelijk van of de eindniveau-formule van Java of de niveaustijging-formule van Bedrock van toepassing is.