MC Toolkit

คู่มือ / คำสั่งและข้อมูล

Predicate ที่มีเงื่อนไขเดียวจะไม่มี wrapper ซึ่งเป็นการเปลี่ยนรูปทรงที่แท้จริง

เงื่อนไขเดียวคือตัว object เอง ส่วนสองเงื่อนไขขึ้นไปจะถูกห่อด้วย all_of หรือ any_of พร้อมกับประเภทเงื่อนไขทั้งแปด และเหตุผลที่การกลับด้านเป็น wrapper ไม่ใช่ flag

Predicate ของ datapack คือไฟล์ JSON ที่อธิบายเงื่อนไข และโครงสร้างของมันจะเปลี่ยนไปตามจำนวนเงื่อนไขที่คุณมี นี่คือส่วนที่ทำให้คนสับสนเมื่อคัดลอกตัวอย่างและนำไปขยายต่อ

หนึ่งไม่ใช่รายการของหนึ่ง

เงื่อนไขรูปแบบผลลัพธ์
0{}
1ตัว object เงื่อนไขเอง
2+{ "condition": "minecraft:all_of", "terms": [ … ] }

ไม่มี wrapper ห่อหุ้มเงื่อนไขเดียว เมื่อเพิ่มเงื่อนไขที่สอง ไฟล์ทั้งหมดจะเปลี่ยนรูปทรงไป เงื่อนไขเดิมจะกลายเป็นองค์ประกอบแรกของอาร์เรย์ terms ภายใต้ root ใหม่ อะไรก็ตามที่อ่านหรือสร้างสิ่งเหล่านี้จะต้องจัดการทั้งสองรูปแบบ และตัวอย่างที่สร้างจากเงื่อนไขเดียวจะไม่แสดงให้เห็นถึงรูปทรงที่คุณต้องการในทันทีที่คุณเพิ่มเงื่อนไขอื่น

any_of คือตัวรวมทางเลือก: ทุก เงื่อนไขต้องผ่าน หรือ เงื่อนไขใด เงื่อนไขหนึ่งในนั้น

การกลับด้านก็เป็น wrapper เช่นกัน ไม่ใช่ flag

ไม่มีฟิลด์ "invert": true เงื่อนไขที่ถูกปฏิเสธจะถูกห่อหุ้ม:

{ "condition": "minecraft:inverted", "term": { …the original condition… } }

โปรดสังเกต term ซึ่งเป็นเอกพจน์ — inverted รับเพียงหนึ่งเดียว ในขณะที่ all_of และ any_of รับอาร์เรย์ terms คีย์สองตัวที่ดูคล้ายกันแต่มีรูปทรงต่างกัน และการกลับด้านจะใช้กับแต่ละเงื่อนไข ดังนั้น predicate สามารถผสมเงื่อนไขที่กลับด้านและเงื่อนไขปกติได้อย่างอิสระภายใน all_of เดียว

ประเภทเงื่อนไขทั้งแปด

entity_properties            random_chance
value_check                  random_chance_with_looting
weather_check                time_check
location_check               match_tool

random_chance_with_looting เป็นสิ่งที่เราควรหยุดพิจารณา: มันรับค่าโอกาสพื้นฐาน (base chance) และ ค่าโชค (Luck) looting_multiplier ดังนั้นความน่าจะเป็นจะปรับตามระดับการฉกชิง (Looting) ของผู้สังหาร นั่นทำให้มันมีความหมายเฉพาะในบริบทที่มีผู้สังหารอยู่เท่านั้น — มันเป็นเงื่อนไขอัตราการดรอป ไม่ใช่ประตูสุ่มอเนกประสงค์ ส่วน random_chance ธรรมดาคือสิ่งที่ควรใช้ในที่อื่นๆ

value_check เปรียบเทียบตัวเลขกับหนึ่งในสามแหล่งที่มา: ระดับการร่ายเวท (enchantment level), โชค (luck), หรือนิพจน์ที่กำหนดเองที่คุณแก้ไขลงใน JSON ด้วยตนเองหลังจากคัดลอก

ตัวเลือกคือชุดข้อมูล vanilla เป๊ะๆ

เป็นสิ่งสำคัญที่ควรทราบเมื่อคุณตรวจสอบว่า ID ชีวนิเวศ (biome) หรือโครงสร้าง (structure) นั้นมีอยู่จริงหรือไม่: รายการดรอปดาวน์ของตัวสร้างไม่ใช่ตัวอย่างที่คัดสรรมา

  • 66 ชีวนิเวศ — ชีวนิเวศทุกชนิดในเกม ไม่มีอะไรขาดหายและไม่มีอะไรถูกสร้างขึ้นมาใหม่
  • 34 โครงสร้าง — เช่นกัน
  • 18 แท็กบล็อกและ 15 ไอเทม ซึ่ง เป็น ชุดย่อยที่ใช้งานได้

สิ่งนี้ได้รับการยืนยันจากข้อมูลการลงทะเบียนของเกมเอง ไม่ใช่การสันนิษฐาน ดังนั้นหาก ID หายไปจากรายการชีวนิเวศหรือโครงสร้าง แสดงว่า ID นั้นไม่มีอยู่จริง สำหรับแท็กบล็อกและไอเทมนั้นตรงกันข้าม: การไม่มีอยู่หมายความเพียงว่าตัวเลือกไม่ได้แสดงรายการ และการพิมพ์ ID ด้วยตนเองก็ใช้ได้ดี

ตัวสร้างเพรดิเคตและเงื่อนไข →

คู่มือเพิ่มเติม

ดูทั้งหมด →

หัวผู้เล่นแบบกำหนดเองจัดเก็บ URL ที่อยู่ใน JSON แบบ base64 ไม่ใช่รูปภาพ

คอมโพเนนต์โปรไฟล์จะเก็บ base64 ของ {textures:{SKIN:{url:…}}} นี่คือเหตุผลที่รูปลักษณ์ของหัวผู้เล่นจะถูกกำหนดตายตัว ณ เวลาที่สร้าง และเป็นเหตุผลที่ฐานข้อมูลสามารถมีรายการได้หลายหมื่นรายการ

2026-08-01คำสั่งและข้อมูล

ชื่อผู้ใช้ Minecraft มีได้ 1-16 ตัวอักษรจากสามสิ่งนี้เท่านั้น และ UUID มีสองรูปแบบ

ตัวอักษร, ตัวเลข, ขีดล่าง ไม่มีขีดกลาง, ไม่มีจุด, ไม่มีช่องว่าง และ UUID สามารถใช้ได้ทั้งแบบมีหรือไม่มีขีดกลาง ซึ่งเป็นเหตุผลว่าทำไมการค้นหาหนึ่งถึงล้มเหลวในขณะที่อีกอันที่เหมือนกันกลับใช้งานได้

2026-08-01คำสั่งและข้อมูล

ไฟล์โครงสร้าง .nbt เก็บดัชนีพาเล็ต ไม่ใช่ชื่อบล็อก — นี่คือเหตุผลที่มันมีขนาดเล็ก

สามคีย์หลักที่เก็บโครงสร้างทั้งหมด: ขนาด, พาเล็ต และบล็อก บล็อกแต่ละบล็อกเป็นจำนวนเต็มที่ชี้ไปยังพาเล็ต ดังนั้นปริมาตรหินขนาด 32³ จึงใช้เพียงหนึ่งสตริงและตัวเลข 32,768 ตัว

2026-08-01คำสั่งและข้อมูล

กำลังหาเครื่องมือ Minecraft อื่นอยู่ไหม

ชุดเครื่องมือสร้าง ดู และแปลงไฟล์ที่ทำงานในเบราว์เซอร์ ฟรีทั้งหมด