تكلفة السندان في 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 هي المُطبَّقة.