จัดการผู้เล่น

เพิ่ม/ลบผู้เล่นด้วยชื่อหรือ UUID นำเข้าจาก whitelist.json เข้าใจสถานะ และ Can Update

ภาพรวมหน้าผู้เล่น

แท็บ ผู้เล่น แสดงรายชื่อผู้เล่นของ Instance พร้อมหัวตัวละคร ชื่อ UUID สถานะ สิทธิ์ และสวิตช์ Can Update มีช่องค้นหา (ชื่อหรือ UUID) ด้านบนตาราง และบรรทัดสรุปจำนวน เช่น "ผู้เล่นทั้งหมด 12 · รอตรวจสอบ 3"

คอลัมน์ความหมาย
Playerหัวตัวละคร (ดึงจาก UUID ทำให้ไม่เสียถ้าผู้เล่นเปลี่ยนชื่อ) ชื่อ และ UUID
Statusสถานะของแถว (ดูหัวข้อสถานะ)
Permissionsชิปแสดงสิทธิ์ที่ผู้เล่นมี กดเพื่อแก้ไข
Can Updateช่องติ๊ก เปิด/ปิดรายคน

ปุ่มบนหัวหน้า

ปุ่มด้านบนขวาเป็นไอคอน เอาเมาส์ไปชี้เพื่อดูชื่อปุ่ม:

ปุ่มทำอะไร
ตรวจสอบรายการที่ไม่พบอีกครั้งขึ้นเฉพาะเมื่อมีรายการที่ไม่พบใน Mojang ส่งไปตรวจใหม่
จัดการสิทธิ์สร้าง แก้ไข ลบกลุ่มสิทธิ์ (ดู สิทธิ์)
ตั้งค่า Revo Figuraขึ้นเฉพาะเมื่อผู้ดูแลระบบเปิดใช้ ดู ซิงก์ผู้เล่นไป Revo Figura
ซิงก์ไป Revo Figuraขึ้นเฉพาะ Instance ที่เชื่อมต่อ Revo Figura แล้ว
whitelist.jsonส่งออกรายชื่อ (ดูหัวข้อส่งออกด้านล่าง)
เพิ่มผู้เล่นเปิดหน้าต่างเพิ่มผู้เล่น

ติ๊กเลือกผู้เล่นหลายคนได้ แถบใต้ปุ่มจะแสดง "เลือกแล้ว N คน" พร้อมปุ่ม ตั้งสิทธิ์ เปิดอัปเดต ปิดอัปเดต และ ลบ สำหรับรายคน กดปุ่ม ⋯ ท้ายแถว หรือคลิกขวาที่แถว เพื่อแก้สิทธิ์ เปิด/ปิดอัปเดต หรือลบออกจาก Instance

เพิ่มผู้เล่น

กด เพิ่มผู้เล่น แล้ววางชื่อผู้เล่นหรือ UUID ลงในช่องข้อความ คั่นด้วยบรรทัดใหม่ , ; หรือช่องว่าง ปนกันได้ ระบบจะนับจำนวนรายการให้ และตัดรายการซ้ำออก

รูปแบบตัวอย่างหมายเหตุ
ชื่อ MinecraftMCKimKunG1–16 ตัวอักษร ใช้ได้เฉพาะ A–Z, a–z, 0–9 และ _
UUID069a79f4-44e9-4726-a5be-fca90e38aaf5มีหรือไม่มีขีดก็ได้ แม่นยำที่สุดเพราะ UUID ไม่เปลี่ยนแม้เปลี่ยนชื่อ

เมื่อกดเพิ่ม ระบบแจ้งผลเป็นข้อความ เช่น "เพิ่มแล้ว 5 · กำลังตรวจสอบ 3 · มีอยู่แล้ว 2" และถ้ามีรายการรูปแบบไม่ถูกต้องจะแจ้งแยก (แสดง 5 รายการแรก)

  • เพิ่มได้ครั้งละหลายร้อยคน - ถ้าเกิน 1000 รายการ ระบบแบ่งส่งหลายรอบให้เอง
  • รายการที่มีอยู่ใน Instance แล้วจะถูกนับเป็น "มีอยู่แล้ว" และไม่เพิ่มซ้ำ

นำเข้าจาก whitelist.json

ในหน้าต่างเพิ่มผู้เล่น กด นำเข้าจาก whitelist.json แล้วเลือกไฟล์ whitelist.json ของเซิร์ฟเวอร์ Minecraft รูปแบบมาตรฐานคือ:

json
[
  { "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5", "name": "Notch" },
  { "uuid": "853c80ef-3c37-49fd-aa49-938b674adae6", "name": "jeb_" }
]
  • ระบบอ่านไฟล์ในเบราว์เซอร์และสรุป "ชื่อไฟล์ · N ผู้เล่น" (บอกจำนวนที่ข้ามเพราะอ่านไม่ได้) กดเครื่องหมาย X เพื่อเอาออก
  • รวมกับรายชื่อที่พิมพ์เองได้ รายการซ้ำถูกตัดออกก่อนส่ง
  • รายการที่มีแต่ชื่อ (ไม่มี uuid) ก็นำเข้าได้เช่นกัน ส่วนรายการที่อ่านไม่ได้จะถูกข้ามและนับให้
  • ใช้ UUID ระบุตัวผู้เล่น ส่วนชื่อในไฟล์เป็นเพียงตัวช่วยแสดงผลระหว่างรอ ระบบจะไม่เชื่อชื่อนี้โดยไม่ตรวจสอบกับ Mojang
ถ้าชื่อใน whitelist เก่าแล้ว

ระบบตรวจชื่อกับ UUID ผ่าน Mojang ถ้าตรงกันก็ยืนยันได้เลย (ใช้ request น้อย) ถ้าผู้เล่นเปลี่ยนชื่อแล้ว ระบบจะค้นหาด้วย UUID แทน จึงไม่ถูกตีว่า "ไม่พบ" เพียงเพราะชื่อเก่า

ส่งออกเป็น whitelist.json

ปุ่ม whitelist.json บนหัวหน้าผู้เล่นดาวน์โหลดไฟล์ whitelist.json สำหรับเซิร์ฟเวอร์ Minecraft ถ้าไม่ได้ติ๊กเลือกใครจะส่งออกผู้เล่นทั้งหมด ถ้าติ๊กเลือกไว้ จะส่งเฉพาะที่เลือก (ปุ่มเปลี่ยนเป็น whitelist.json (n)) ไฟล์อยู่ในรูปแบบเดียวกับที่นำเข้าได้ และ UUID มีขีดตามมาตรฐาน

  • เกมต้องใช้ทั้ง UUID และชื่อ จึงส่งออกเฉพาะผู้เล่นสถานะ พร้อมใช้งาน คนที่ยังรอตรวจสอบหรือไม่พบใน Mojang จะถูกข้าม และข้อความแจ้งจำนวนที่ข้าม
  • ถ้าไม่มีผู้เล่นพร้อมใช้งานเลย จะแจ้งเตือนแทนการดาวน์โหลดไฟล์ว่าง

ซิงก์ให้ตรงกับ whitelist.json

หลังนำเข้าไฟล์ จะมีช่อง ซิงก์ให้ตรงกับรายการนี้ ถ้าติ๊ก ระบบจะทำให้รายชื่อผู้เล่นของ Instance ตรงกับไฟล์ ไม่ใช่แค่เพิ่ม:

  • เพิ่มคนที่อยู่ในไฟล์แต่ยังไม่มีใน Instance
  • ลบผู้เล่นใน Instance ที่ไม่อยู่ในไฟล์ (รวมรายชื่อที่พิมพ์เองในช่องข้างบนด้วย ถือเป็นส่วนหนึ่งของรายการ)
  • ก่อนทำจริงจะแสดงรายชื่อคนที่จะถูกลบและจำนวน ให้ยืนยันอีกครั้ง (ไม่มีใครถูกลบถ้าไม่ยืนยัน)
ผู้เล่นใน Instanceผลของการซิงก์
UUID อยู่ในไฟล์คงไว้ (สิทธิ์และ Can Update เดิมไม่เปลี่ยน)
ไม่อยู่ในไฟล์ถูกลบ รวมถึงสิทธิ์ที่เคยกำหนด
ยังรอตรวจสอบ และ UUID หรือชื่อ (กรณีรายการมีแต่ชื่อ) อยู่ในไฟล์คงไว้
ชื่อตรงกับชื่อในไฟล์ แต่ UUID ไม่ตรงถูกลบ (ชื่อข้าง UUID ในไฟล์เป็นแค่ตัวช่วยแสดงผล ไม่ใช้ตัดสินว่าใครอยู่)

พิมพ์รายชื่อเพิ่มตอนซิงก์

ชื่อหรือ UUID ที่พิมพ์ในช่องด้านบนของหน้าต่าง จะถูกรวมกับ whitelist.json เป็นรายการเดียวก่อนซิงก์ (รายการซ้ำตัดออกให้) รายการรวมนี้คือ "รายชื่อที่ต้องการ" ของการซิงก์:

คนคนนั้นผลของการซิงก์
อยู่ใน whitelist.jsonเพิ่มถ้ายังไม่มี / คงไว้ถ้ามีอยู่แล้ว
พิมพ์เองในช่องด้านบน (ไม่อยู่ในไฟล์)เพิ่มถ้ายังไม่มี และ ไม่ถูกลบ
อยู่ใน Instance แต่ไม่อยู่ทั้งในไฟล์และในช่องที่พิมพ์ถูกลบ
  • ใช้เก็บคนที่ไม่อยู่ใน whitelist ของเซิร์ฟเวอร์ไว้ได้ เช่น แอดมินหรือทีมงาน โดยพิมพ์ชื่อไว้ในช่องตอนซิงก์ทุกครั้ง
  • ตัวเลข "N รายการ" ใต้ช่องคือจำนวนของรายการรวม และกรอบซิงก์ระบุไว้ว่ารวมช่องด้านบน
  • ที่พิมพ์เป็น ชื่อ จะจับคู่ด้วยชื่อ (ไม่สนตัวพิมพ์เล็ก/ใหญ่) ถ้าผู้เล่นคนนั้นอยู่ใน Instance แล้วและชื่อตรงกันก็ถูกเก็บไว้ ที่พิมพ์เป็น UUID จะแม่นยำกว่า
  • ชื่อที่พิมพ์ผิดรูปแบบหรืออ่านไม่ได้ ทำให้ซิงก์ถูกปฏิเสธทั้งหมดตามกติกาด้านบน ไม่ใช่ถูกข้ามไป
  • ช่องซิงก์ปรากฏเมื่อนำเข้าไฟล์แล้วเท่านั้น ถ้าพิมพ์อย่างเดียวโดยไม่นำเข้าไฟล์ จะเป็นการเพิ่มธรรมดา ไม่มีการลบ
ซิงก์ลบคนได้ ระวังไฟล์ไม่ครบ

ถ้ามีรายการใดในไฟล์ที่อ่านไม่ได้ ระบบปฏิเสธการซิงก์ทั้งหมดและไม่แตะอะไรเลย เพื่อไม่ให้ไฟล์ที่อ่านได้ครึ่งเดียวทำให้ลบผิดคน ซิงก์ได้สูงสุด 5,000 รายการต่อครั้ง และการลบกู้คืนไม่ได้ (ต้องเพิ่มผู้เล่นและตั้งสิทธิ์ใหม่)

สถานะของผู้เล่น

สถานะความหมาย
พร้อมใช้งานรู้จักผู้เล่นแล้ว (มี UUID และชื่อจริงจาก Mojang)
รอตรวจสอบเพิ่มแล้วแต่ยังตรวจกับ Mojang ไม่เสร็จ ระบบกำลังทยอยตรวจในเบื้องหลัง หน้าจะรีเฟรชเองทุก 4 วินาทีจนกว่าจะเสร็จ
ไม่พบใน MojangMojang ตอบว่าไม่มีผู้เล่นชื่อ/UUID นี้ (อาจพิมพ์ผิด) ระบบจะไม่ลองซ้ำเองจนกว่าคุณสั่ง

แถวที่ยังไม่มีชื่อจริง (เพิ่มด้วย UUID) จะแสดง "(ยังไม่ทราบชื่อ)" และใช้หัวตัวละครจาก UUID ไปก่อน

ระบบตรวจสอบผู้เล่นทำงานอย่างไร

Mojang จำกัดจำนวนการเรียก API เพื่อให้เพิ่มผู้เล่นเป็นร้อยคนได้ ระบบจึงไม่ตรวจทีละคนแบบรอ แต่ทำเป็นงานเบื้องหลัง:

  1. ผู้เล่นที่ระบบรู้จักอยู่แล้วจะถูกเพิ่มทันที (ชื่อที่ใช้ทางลัดนี้ต้องเห็นผู้เล่นนั้นภายใน 7 วัน เพราะชื่ออาจถูกคนอื่นใช้ต่อ)
  2. ที่เหลือเป็น "รอตรวจสอบ" แล้วระบบตรวจกับ Mojang แบบรวมชุด - ชื่อทีละ 10 คนต่อ 1 request (500 ชื่อ ≈ 50 request) ส่วน UUID ตรวจทีละตัว
  3. ถ้า Mojang ตอบว่าเรียกถี่เกินไป ระบบพักตามเวลาที่กำหนดแล้วทำต่อ ไม่ทำให้ข้อมูลเสีย และจะลองงานที่ค้างอยู่ทุก 1 นาที
  4. เมื่อผู้เล่นล็อกอินผ่าน launcher ครั้งแรก ระบบรู้ UUID และชื่อจริงโดยไม่ต้องเรียกเพิ่ม จึงจับคู่แถวที่ค้างให้อัตโนมัติ (รวมแถวที่ "ไม่พบ" ด้วย)
เรื่องรายการที่เพิ่มด้วยชื่ออย่างเดียว

แถวที่เพิ่มด้วยชื่อและยังไม่ได้ตรวจสอบ จะผูกกับผู้ที่ล็อกอินด้วยชื่อนั้นเป็นคนแรก ถ้าชื่อนั้นถูกผู้เล่นคนอื่นใช้ไปแล้ว สิทธิ์จะตกเป็นของคนนั้น ถ้าต้องการความแม่นยำสูงสุด ให้เพิ่มด้วย UUID หรือนำเข้าจาก whitelist.json

ตรวจสอบรายการที่ไม่พบอีกครั้ง

เมื่อมีแถว "ไม่พบใน Mojang" จะมีปุ่ม ตรวจสอบรายการที่ไม่พบอีกครั้ง กดเพื่อส่งกลับเข้าคิวตรวจใหม่ (เช่น หลังแก้ชื่อที่พิมพ์ผิดแล้ว หรือ Mojang มีปัญหาชั่วคราว)

Can Update

คอลัมน์ Can Update เป็นสวิตช์ต่อผู้เล่นที่เก็บไว้กับ Instance ค่าเริ่มต้นคือปิด ติ๊กที่แถวเพื่อเปิด/ปิดรายคน (มีข้อความแจ้งเมื่อสำเร็จ เช่น "เปิดอัปเดตให้ Notch แล้ว") หรือเลือกหลายคนแล้วกด เปิดอัปเดต / ปิดอัปเดต ก็ได้ จำนวนผู้เล่นที่เปิดอยู่แสดงในการ์ด "ผู้เล่น" ที่หน้า ข้อมูล

ข้อมูล

สวิตช์นี้ถูกเก็บเป็นข้อมูลของผู้เล่นใน Instance การนำไปบังคับใช้ขึ้นกับฝั่ง launcher

เลือกหลายคนและลบ

  1. 1

    ติ๊กช่องหน้าแถว (หรือช่องที่หัวตารางเพื่อเลือกทั้งหมดที่เห็น)

  2. 2

    เลือกการทำงานที่ปุ่มด้านบน

    ตั้งสิทธิ์ (N), เปิดอัปเดต, ปิดอัปเดต หรือ ลบที่เลือก (N)

  • ลบผู้เล่น (รายคนด้วยถังขยะ หรือหลายคนด้วยปุ่มด้านบน) มีหน้าต่างให้ยืนยันก่อน
  • ลบแค่ เอาออกจาก Instance นี้ เท่านั้น ไม่ได้ลบบัญชีผู้เล่น และผู้เล่นคนเดิมถูกเพิ่มกลับได้เสมอ

ต่อไป: แจกไฟล์ต่างกันด้วยสิทธิ์

เอกสารต่างๆ

Term of servicePrivacy Policy

Dimension Studio

ไดแมนชั่น สตูดิโอ

ดิสคอร์ด :

Dimension Studio

เว็บไซต์ :

Dimension Studio

ยูทูป :

Dimension Studio

Copyright © 2024-2026 บริษัท เน็กชันนารี จำกัด (NEXIONARY Company Limited). All rights reserved.

ทะเบียนเลขที่ 50105568159679

Dimension Launcher ไม่มีส่วนเกี่ยวข้องกับ Mojang AB หรือ Microsoft Corporation