الخلاصة المختصرة: معظم المحتوى يُنقل، لكن ليس «بلا أي فقد بنسبة 100%»

عند تحويل عالم Java إلى إصدار Bedrock، يُنقل معظم المحتوى، لكن قليلًا من المحتوى الخاص بإصدار Java يُستبدل أو يُدرَج على حدة — وذلك لأن صيغة العالم وبعض الآليات تختلف أصلًا بين الإصدارين. ما يوفّره TopoBlocks هو تحويل مُتحقَّق منه، أحادي الاتجاه من إصدار Java إلى إصدار Bedrock (لا يمكن إعادة إصدار Bedrock إلى Java)، ولا يَعِد أبدًا بنقل «بلا أي فقد بنسبة 100%».

المحتوى الذي يُنقل عادةً:

  • التضاريس والارتفاعات — التضرّس السطحي والجبال والمسطّحات المائية والشكل العام.
  • معظم الكتل — بما في ذلك الكتل ذات الحالات مثل الدرج وأوراق الشجر والكتل المشبعة بالماء (waterlogged).
  • الحاويات وما بداخلها — محتويات الصناديق وصناديق الشولكر وغيرها.
  • تخطيط البنى والمباني — المباني التي شيّدتها (المكوّنة من كتل) تُحفظ ككل.

المحتوى الذي قد يُستبدل بمكافئ متوافق أو يُنقل إلى «التقرير التفصيلي»:

  • الكيانات الخاصة بإصدار Java — ما لا يوجد له تطبيق مقابل في إصدار Bedrock يُستبدل أو يُدرَج.
  • حزم البيانات / حزم الموارد — آليتها تختلف عن حزم السلوك/الموارد في إصدار Bedrock، فلا تُطبَّق تلقائيًا عادةً، بل تُدوَّن في التقرير لتتعامل معها بنفسك.
  • بعض سلوكيات الريدستون وكتل الأوامر — فروق التوقيت/الصياغة قد تؤدي إلى اختلاف في السلوك.
  • بيانات اللاعب — قد تُستبدل أو تُدرَج على حدة، والتقرير هو المرجع.

إذا أردت أولًا فهم الفروق الجوهرية بين الإصدارين، فاطّلع على ما الفرق بين إصدار Java وإصدار Bedrock.

اطّلع على درجة التوافق أولًا، ثم قرّر إن كنت ستحوّل

لن يدعك TopoBlocks «تعرف النتيجة بعد التحويل فقط». قبل الدفع يعطيك درجة توافق مجانية، تقدّر فيها البنود السابقة على عالمك تحديدًا: ما يُتوقَّع نقله بالكامل وما قد يُستبدل أو يُنقل إلى التقرير، لتقرر وأنت على بيّنة قبل أن تدفع.

  • الدفع لكل عملية، واسترداد عند الفشل. التحويل بالدفع لكل عملية، والسعر هو المعتمد داخل التطبيق؛ وإن فشلت المهمة يكون الاسترداد تلقائيًا.
  • لا يستبدل الملف الأصلي أبدًا. ينشئ التحويل ملف .mcworld جديدًا قابلًا للاستيراد، ويبقى عالم Java الأصلي مع بصمته (hash) محفوظًا وقابلًا للتتبّع، وهذا خط أحمر في المنتج.
  • تقرير تفصيلي بكل تغيير بعد الانتهاء. أيّ الكتل استُبدلت، وأيّ الكيانات/البيانات نُقلت خارجًا، مُدوَّن بندًا بندًا، دون أي مفاجآت.

إن أردت البدء مباشرةً، فاطّلع على الخطوات التفصيلية في التحويل من Java إلى Bedrock (يعمل على iPhone).

الريدستون وكتل الأوامر والحزم: أين يحدث «الاختلاف» غالبًا

إذا كان عالمك يعتمد بشدة على دوائر الريدستون أو كتل الأوامر أو حزم البيانات/الموارد، فهذا الجزء يستحق الانتباه مسبقًا:

  • الريدستون/كتل الأوامر: يختلف توقيت الريدستون وصياغة الأوامر بين إصدار Java وإصدار Bedrock، فقد يختلف سلوك الدوائر المعقّدة أو منطق الأوامر في إصدار Bedrock أو يحتاج إلى تعديل يدوي. يحاول التحويل نقلها قدر الإمكان ويوثّقها في التقرير، لكنه لا يَعِد بتطابق الريدستون بنسبة 100%. للمزيد راجع ماذا يحدث للريدستون/كتل الأوامر عند التحويل من Java إلى Bedrock.
  • حزم البيانات/الموارد: آليتها تختلف عن حزم السلوك/الموارد في إصدار Bedrock، فلا تُطبَّق تلقائيًا داخل العالم عادةً، بل تُدرَج في التقرير التفصيلي، وتحتاج إلى التعامل معها بالطريقة المقابلة في جانب إصدار Bedrock.

راجع كل ذلك مقارنةً بالتقرير، ثم ركّز بعد الاستيراد على فحص الأجزاء المُشار إليها، لتتجنّب فجوة «ظننتُه نُقل، لكن سلوكه تغيّر فعليًا».