MC Toolkit

أدلة / البناء والموارد

نحيف أم كلاسيكي: اللعبة تقرأ حسابك، والأداة عليها أن تخمّن من 24 بكسل

تأخذ اللعبة الطراز النحيف أو الكلاسيكي من إعداد الجلد في حسابك، لا من ملف PNG. أما الأداة التي تُعطى ملف PNG مجردًا فعليها أن تخمّن من عمودين يتركهما الذراع النحيف فارغين. مع خريطة UV الكاملة وسبب انعكاس الجلود القديمة 64×32.

لا شيء في ملف PNG للجلد يقول "نحيف". لا يوجد علم ولا اصطلاح لتسمية الملفات — واللعبة لا تنظر إلى البكسلات أبدًا لتعرف ذلك. إنها تأخذ الطراز من إعداد model الذي يربطه حسابك بالجلد (الخيار الذي تختاره عند رفعه)، والملف الشخصي الذي لا جلد له يحصل على واحد من 18 جلدًا افتراضيًا، 9 نحيفة و9 كلاسيكية، يُختار من UUID الخاص به.

الأداة الوحيدة التي تُعطى ملف PNG مجردًا — محرر أو مُنشئ حزم أو عارض — هي التي عليها أن تستنتج الطراز، وهي تفعل ذلك بالنظر إلى مستطيل محدد بأبعاد 2 × 12 وإحصاء كم بكسل فيه موجود فعلًا.

الاختبار

sample  x 54–55, y 20–31        — 2 wide, 12 tall = 24 pixels
count   pixels with alpha > 0
slim    if fewer than 6 are opaque

الأذرع الكلاسيكية عرضها 4 بكسلات؛ والأذرع النحيفة 3. أوجه الذراع النحيف محزومة ببكسل أضيق، لذا ينزاح الوجهان الجانبي والخلفي إلى اليسار ويبقى العمودان الأخيران من كتلة الذراع، x 54–55، فارغين. في الجلود الافتراضية من Mojang نفسها، هذا المستطيل يساوي 0 من 24 معتمًا في التسعة النحيفة كلها و24 من 24 في التسعة الكلاسيكية كلها — أربعة وعشرون بكسل تكفي للتمييز.

العتبة هي 6 من 24، وليس 1 — يجب أن يُملأ ربع العمود قبل أن يُحتسب كلاسيكيًا. هذا التسامح مهم: الجلد النحيف الذي فيه بكسلات شاردة قليلة في العمود الميت يظل يُقرأ نحيفًا، وهذا ما تريده، لأن تلك الشوارد غالبًا ما تكون حادث تحرير لا نية مقصودة.

وهذا يعني أيضًا أن نمط الفشل صامت. إذا رسمت جلدًا كلاسيكيًا لكنك استخدمت تلك الأعمدة استخدامًا خفيفًا فقط — حد رفيع أو بكسلا تظليل — فقد تهبط تحت 6 ويُكتشف تلقائيًا كنحيف، فتفقد بكسلًا من عرض الذراع دون أي شيء يفسّر السبب. إذا ظهر الجلد بالطراز الخطأ في أداة ما، فتلك الأعمدة هي المكان الذي يجب أن تنظر فيه — وفي اللعبة، الإعداد في حسابك هو المكان.

خريطة UV كاملة

كل جزء من الجلد مستطيل ثابت، ولكل جزء طبقة تراكب في مكان آخر على الورقة:

الجزءالأساسالتراكبالإزاحةالحجم
الرأس(8, 8)القبعة (40, 8)32 يمينًا8 × 8
الجسم(20, 20)السترة (20, 36)16 للأسفل8 × 12
الذراع اليمنى(44, 20)الكم (44, 36)16 للأسفل4 × 12
الساق اليمنى(4, 20)البنطال (4, 36)16 للأسفل4 × 12
الذراع اليسرى(36, 52)الكم (52, 52)16 يمينًا4 × 12
الساق اليسرى(20, 52)البنطال (4, 52)16 يسارًا4 × 12

خمس من التراكبات الستة تقع على مسافة 16 بكسل بالضبط من أساسها — لكن ليس في الاتجاه نفسه. الأجزاء الثلاثة الأصلية تتحرك 16 للأسفل. أما الذراع اليسرى والساق اليسرى، اللتان أُضيفتا لاحقًا وحُشرتا في النصف السفلي حيث لم تكن هناك مساحة تحتهما، فتتحركان 16 جانبيًا بدلًا من ذلك — وفي اتجاهين متضادين إحداهما عن الأخرى.

القبعة هي الوحيدة التي لا تبعد 16 إطلاقًا: إنها 32 إلى اليمين، في الصف نفسه الذي فيه الرأس.

إذن قاعدة "التراكب تحت الأساس" تصح لنصف الورقة بالضبط. نسخ مستطيل الأساس وإزاحته للأسفل للعثور على تراكبه ينجح مع الجسم والذراع اليمنى والساق اليمنى، ويهبط بصمت على الجزء الخطأ في الثلاثة الأخرى.

في الجلد النحيف يُقرأ كل مستطيل ذراع بعرض 4 على أنه بعرض 3 بدلًا من ذلك. الأوجه الأمامية لا تتحرك، لكن كل ما يأتي بعدها يتحرك: الوجه الجانبي والوجه الخلفي يبدآن بكسلًا واحدًا أبعد إلى اليسار، والوجه الخلفي أضيق ببكسل، وهذا ما يترك x 54–55 فارغين.

الصيغة القديمة 64 × 32 ليس فيها جانب أيسر إطلاقًا

الجلد قبل 1.8 حجمه 64 × 32 — النصف السفلي من الورقة ببساطة غير موجود، وهو المكان الذي تسكن فيه الذراع اليسرى والساق اليسرى. لا يوجد شيء لرسمهما منه.

الحل هو الانعكاس: تُنسخ الساق اليمنى (0, 16) إلى (16, 48) والذراع اليمنى (40, 16) إلى (32, 48)، كلتاهما مقلوبة أفقيًا. لهذا تكون الجلود القديمة متناظرة تمامًا ولا يلزم أن تكون الجلود الحديثة كذلك — اللاتناظر هو الشيء الوحيد الذي لا تستطيع صيغة 64 × 32 التعبير عنه، وأي جلد قديم تحوّله يُفرض عليه التناظر شاء أم أبى.

ملف المحرر 128 × 128 هو التخطيط نفسه بحجم مضاعف

تقبل Java صيغة 64 × 64 أو الصيغة القديمة 64 × 32 وترفض أي شيء آخر. محرر الجلود لـ Bedrock في هذا الموقع يعمل بدقة 128 × 128 ولا يقبل أي شيء آخر — لكن ذلك الملف هو تخطيط UV نفسه مرسومًا بدقة مضاعفة، كل جزء بإحداثيات مضاعفة لإحداثيات Java، وليس صيغة مختلفة.

العائق في الأدوات لا في التخطيط. خط أنابيب النسيج في كل إصدار محرر مُقاس على رقمه الخاص، لذا لا يفتح أي منهما ملف الآخر، وملف PNG بحجم 128 × 128 يُعطى لـ Java يُرفض بدل أن يُعرض بنصف الحجم. التحويل هو مجرد مقياس 2× ميكانيكي، ولهذا يتعامل محرر الجلود مع الاثنين كإصدارين منفصلين لا كلوحة واحدة.

صانع الصور الرمزية →

المزيد من الأدلة

عرض الكل →