عن المشروع

ريدستور هو مود فابريك صغير لـ ماينكرافت 26.3 يضغط دوائر الريedstone الممكنة بالفعل في الفانيلا إلى كتل فردية، بهدف جعل الأجهزة على الخوادم التقنية قابلة للقراءة ومدمجة. يؤكد المؤلف أن لا شيء يضيفه يتجاوز قدرات البقاء في الفانيلا دون أوامر: بوابة منطقية هي تجميع مشعل ومكرر في خلية واحدة، الهوبر الفلتر هو خلية الفرز بالمقارن الكلاسيكية، ومُحمّل الشانك المخطط هو غرفة استقرار إندير بيرل بدون البيرل. الهدف المعلن هو إزالة الملل، وليس الحدود. hالحالة: مبكر وغير مُصدر. البوابات الثلاث، الساعة، والهوبر الفلتر مكتوبة؛ مُحمّل الشانك محدد لكن غير مُنفذ. معرف المود `redstore` هو اسم رمزي عامل والاسم العام غير مستقر. الكتل الموصوفة في ملف README: - بوابة AND / OR / XOR: لوحات بحجم المكرر مع مدخلين جانبيين ومخرج أمامي واحد، تأخير تيك ريدستون واحد. النقر بالزر الأيمن يعكسها إلى NAND، NOR و XNOR. كل منها تُصنع بلوحة من معدنها الخاص: حديد، نحاس، ذهب. - ساعة ريدستون: تُصدر إشارة دورية. النقر بالزر الأيمن يتنقل بين ثماني إعدادات، من 1 إلى 4 تيك ريدستون لكل طور، كموجة مربعة أو نبضة تيك واحد. تعمل افتراضيًا؛ إشارة على أي جانب توقفها وتظهر شريط الصخر الأساس لمكرر مقفل. - هوبر فلتر: هوبر بفتحة فلتر إضافية، مع قائمة بيضاء/سوداء ووضع مطابقة صارم/مرن. الفلتر يحدد ما قد يدخل؛ أي شيء بالداخل يمكنه دائمًا الخروج. - مُحمّل الشانك: محدد، غير مُنفذ. سيحافظ على الشانك الخاص به محملًا قسريًا ومُحدثًا بالكامل عبر إعادة التشغيل. المتطلبات: ماينكرافت 26.3، فابريك لودر 0.19.5 أو أحدث، فابريك API (مطلوب لبناء كيان الكتلة وربط تبويب الإبداع)، وجافا 25. يجب تثبيته على العميل والخادم معاً لأنه يضيف كتلاً وواجهة. لا يوجد ملف تكوين؛ كل كتلة تتصرف بنفس الطريقة في كل مكان، ويمكن للخادم الذي لا يريد إحداها إزالة وصفتها بحزمة بيانات. البناء: يُوزع المود ككود مصدر. الأمر `./gradlew build` ينتج ملف jar في build/libs/، و `./gradlew runClient` يبدأ عميل تطوير. JDK 25 أو أحدث هو المتطلب الوحيد؛ جرادل يأتي من الغلاف وماينكرافت يُحمّل بواسطة Loom. منذ أن يُشحن ماينكرافت غير مُعتم منذ 26.1، لا توجد خرائط لتطبيقها ولا يعيد Loom تعيين أي شيء: تبعيات المود تستخدم `implementation` والقطعة تأتي من مهمة `jar` العادية. تخطيط المستودع: المجلد `spec/` يحتوي على التصميم المكتوب قبل الكود، ملف لكل كتلة، مع مواصفات مجردة للمكونات المسطحة المشتركة؛ `spec/ideas/` يسجل الأفكار المدروسة والمرفوضة مثل أوضاع البوابات التناظرية. `src/` يحتوي على المود، مع فئات العميل فقط في `src/client`. `buildSrc/` يحتوي على مهمة `generateAssets`. نهج الرسوم: لا توجد نسيج مرسوم يدويًا ولا مخزن في المستودع. كل نسيج هو نسيج فانيلا مع تعديل صغير محدد بدقة، مثال: الهوبر الفلتر هو هوبر مع حافة فمه المعاد تلوينها بخشب إطار العنصر، والبوابة هي لوحة المكرر مع خطها الممحو ولوحة معدنية موضوعة. هذه التعديلات موجودة في `buildSrc/` ككود، ومهمة جرادل `generateAssets` تطبقها وقت البناء، قراءة نسخة المستخدم الخاصة من ماينكرافت والكتابة في `build/`. تعمل تلقائيًا قبل `processResources`، لذا يحصل كل من ملف jar وعميل التطوير على الأصول دون خطوات إضافية. يلاحظ المؤلف نتيجتين: التعديل يظل قابلاً للمراجعة في فرق (diff) ويمكن إعادة تشغيله عندما تُعدّل موجانج نسيجًا أصليًا، والمستودع لا يحتوي أبدًا على نسيج موجانج معدل، فقط الكود الذي يصف التعديل. الترخيص: الكود تحت رخصة BSD 2-Clause. يشير ملف README إلى أن شروط ماينكرافت الخاصة تنطبق فوق ذلك، لأن موجانج تسمح بالمودات طالما لا تُباع أو تُحقق منها أرباح، لذا صيغة الاستخدام التجاري المتساهلة تابعة لإرشادات استخدام موجانج. النسيجات المشتقة ليست ملك المشروع لترخيصها: هي تعديلات على فن موجانج، وشروط موجانج تسمح بتعديل النسيجات الافتراضية للاستخدام الشخصي لكن لا تسمح بإعادة توزيعها. لذلك يُشحن المود ككود مصدر وينشئ النسيجات على جهاز المستخدم من اللعبة التي يمتلكها بالفعل، بدلاً من شحن ملف jar مع التعديلات المدمجة.