خلاصة سريعة: الريدستون وكتل الأوامر تُنقل، لكن لا ضمان لتطابق السلوك
عند تحويل عالم Java يحتوي على دوائر ريدستون وكتل أوامر إلى إصدار Bedrock، يمكن نقل الكتل نفسها في معظمها، لكن سلوكها أثناء التشغيل غير مضمون أن يكون مطابقاً لـ Java. السبب ليس في أداة التحويل، بل في أن آليات اللعبة تختلف أصلاً بين الإصدارين:
- توقيت الريدستون مختلف. يختلف ترتيب تحديث الريدستون وتوقيت انتشار الإشارة بين إصدار Java وإصدار Bedrock، والدوائر التي تعتمد على توقيت دقيق (مثل الساعات السريعة، والمؤقّتات، والمركبات الطائرة) من السهل جداً أن تُنتج نتائج مختلفة.
- سلوك المكابس والمراقبين يختلف. توقيت دفع/سحب المكابس وطريقة إطلاق المراقبين (Observers) ليسا متطابقين تماماً بين الإصدارين، وأبواب المكابس الصامتة والدوائر اللحظية أكثر عرضة للتعطّل.
- صيغة كتل الأوامر غير متبادلة. صيغة الأوامر والمُحدِّدات وبعض التعليمات لا تتطابق واحدة بواحدة بين Java و Bedrock، وقد يحتاج المنطق داخل كتل الأوامر إلى إعادة كتابة ليعمل في Bedrock.
لذلك فإن TopoBlocks لا يَعِد بتطابق الريدستون بنسبة 100% — وهذا قيد على مستوى الآليات، وليس تكاسلاً. إذا أردت أولاً فهم الفروق الجوهرية بين الإصدارين، فانظر ما الفرق بين إصدار Java وإصدار Bedrock.
ماذا يفعل التحويل وماذا لا يفعل
يحاول التحويل نقل أسلاك الريدستون والمكابس والمراقبين والمُكرِّرات/المقارنات وكتل الأوامر نفسها قدر الإمكان، مع الحفاظ على مواقعها وعلاقات الوصل بينها. وهو لا يعيد كتابة توقيت الدوائر بدلاً منك، ولا يترجم صيغة أوامر Java تلقائياً إلى أوامر مكافئة تعمل في Bedrock — هذه الأجزاء التي يتعذّر تنفيذها تُدوَّن في تقرير التغييرات التفصيلي، الذي يخبرك بوضوح بما تم تغييره وما يحتاج إلى معالجة يدوية منك، بدلاً من حذفه بصمت أو التظاهر بالنجاح.
قبل الدفع سترى أولاً درجة التوافق، وبالنسبة للعوالم الثقيلة بالريدستون/الأوامر يمكنك بناءً عليها أن تحكم على ما إذا كان التحويل يستحق العناء، وكم تقريباً من إعادة العمل سيلزم بعده. التحويل بالدفع لكل مرة، مع استرداد تلقائي عند الفشل، والأسعار كما هي داخل التطبيق. والأهم: التحويل لا يستبدل ملفك المصدري أبداً، فيبقى عالم Java الأصلي مع تجزئته (hash) محفوظاً وقابلاً للتتبع، والمُخرَج هو ملف .mcworld جديد بإصدار Bedrock، وإعادة عمل الريدستون لا تؤثر على النسخة الأصلية. للاطّلاع على القائمة الكاملة لـ«ما يمكن نقله وما لا يمكن»، انظر التحويل من Java إلى Bedrock: ما يُنقل وما لا يُنقل.
كيف تضبط الريدستون والأوامر بعد التحويل
- افحص بالمقارنة مع التقرير التفصيلي. اطّلع أولاً على دوائر الريدستون وكتل الأوامر المُعلَّمة في التقرير بـ«تم التغيير» أو «يحتاج إلى معالجة يدوية»، لتدخل اللعبة وأنت على بيّنة.
- اختبر الدوائر الأساسية أولاً. بعد الدخول إلى إصدار Bedrock اختبر أولاً الأجزاء الأكثر اعتماداً على التوقيت (الساعات، وأبواب المكابس، والمزارع التلقائية)، فهذه الأكثر احتمالاً لأن تحتاج إلى ضبط.
- اضبط وفق قواعد Bedrock. غالباً ما تتطلب مشكلات توقيت الريدستون إعادة ترتيب تأخير المُكرِّرات أو تعديل بنية الدائرة؛ أما كتل الأوامر فتحتاج إلى إعادة كتابة المُحدِّدات والتعليمات وفق صيغة Bedrock.
إذا كان عالمك يحتوي على حزم بيانات/حزم موارد أكثر من ريدستون خالص، فتلك آلية أخرى تُعالَج بطريقة مختلفة، انظر كيفية التعامل مع تحويل حزم البيانات/الموارد إلى Bedrock. وإذا أردت فهماً منهجياً لكامل مسار التحويل من Java إلى Bedrock، راجع الدليل المتعمّق التحويل من Java إلى Bedrock.