Minecraft: การปรับแต่งประสิทธิภาพเซิร์ฟเวอร์
คู่มือนี้ถูกสร้างขึ้นด้วยผลิตภัณฑ์ดังต่อไปนี้:
(รายละเอียดอาจแตกต่างกันไปตามผลิตภัณฑ์จากผู้ให้บริการต่างๆ แต่แนวคิดหลักยังคงเหมือนเดิม)
จริงๆ แล้วเกิดอะไรขึ้นระหว่างการปรับแต่ง?
การปรับแต่งเป็นจุดสำคัญสำหรับเซิร์ฟเวอร์เกม Minecraft เพื่อให้สามารถรันได้อย่างลื่นไหล และคุณควรใช้เวลาพอสมควรกับเรื่องนี้บนเซิร์ฟเวอร์สาธารณะ เท่านั้นที่ใช้เวลามากและการทดสอบหลายครั้งจึงจะได้ผลลัพธ์ที่ดีที่สุด ดังนั้นเอกสารนี้จึงไม่จำเป็นต้องทำตามอย่างเคร่งครัด แต่มีไว้เพื่อช่วยให้คุณเดินไปในทิศทางที่ถูกต้อง
ในหลายกรณี การปรับแต่งจะเปลี่ยนแปลงการตั้งค่าจำนวนมากบนเซิร์ฟเวอร์ ซึ่งบางครั้งจะเปลี่ยนพฤติกรรมของเซิร์ฟเวอร์เองอย่างมีนัยสำคัญ รวมถึงการลดบางการตั้งค่าลงเพื่อช่วยลดภาระเซิร์ฟเวอร์และเพิ่มประสิทธิภาพ แต่เพื่อไม่ให้ประสบการณ์การเล่นเกมโดยรวมถูกกระทบมากเกินไป คุณควรหาจุดสมดุลที่เหมาะสมเสมอ
Vanilla
ตัวเลือกในการปรับแต่งเซิร์ฟเวอร์ Vanilla นั้นค่อนข้างจำกัด เพราะมีตัวเลือกการตั้งค่าไม่มากนัก เราพยายามเพิ่มพลังให้เซิร์ฟเวอร์ Vanilla เล็กน้อยด้วยมาตรการดังนี้:
การมองเห็น
มาตรการที่ใช้บ่อยมากคือการลดระยะการมองเห็น ค่าเริ่มต้นของระยะมองเห็นคือ 10 ชิ้นส่วน (chunks) แต่ผู้เล่นหลายคนเล่นด้วยค่าที่น้อยกว่านั้น เช่น 6-8 บางคนตั้งค่าชิ้นส่วนมากเกินไป เช่น 32 ชิ้นส่วน ซึ่งหมายความว่าเซิร์ฟเวอร์ต้องโหลดและประมวลผลชิ้นส่วนทั้งหมดนี้ ซึ่งกินประสิทธิภาพมาก
สำหรับเซิร์ฟเวอร์ Vanilla ระยะการมองเห็นสามารถปรับได้ในไฟล์คอนฟิก "server.properties" โดยต้องแก้ไขค่าที่ชื่อ "view-distance" เพื่อไม่ให้จำกัดประสบการณ์การเล่นเกมมากเกินไป แนะนำให้ตั้งค่านี้ที่ 5-6 ซึ่งช่วยลดภาระเซิร์ฟเวอร์ได้ถึง 50%
เรามีบทความในคู่มือของเราสำหรับเรื่องนี้ สามารถดูได้ที่ นี่
การบีบอัดข้อมูล
บนเซิร์ฟเวอร์จะมีการแลกเปลี่ยนข้อมูลอย่างต่อเนื่องระหว่างเซิร์ฟเวอร์กับผู้เล่นที่เชื่อมต่อ การเคลื่อนไหวของผู้เล่นถูกส่งไปยังเซิร์ฟเวอร์ และเซิร์ฟเวอร์จะส่งข้อมูลนี้ต่อไปยังผู้เล่นคนอื่นๆ รวมถึงการกระทำของผู้เล่นหรือเหตุการณ์ในโลก เช่น การระเบิด ก็เป็นส่วนหนึ่งของข้อมูลที่ถูกส่งซ้ำๆ
เพื่อให้การแลกเปลี่ยนข้อมูลนี้มีประสิทธิภาพมากขึ้น ขนาดของข้อมูลที่บีบอัดสามารถเพิ่มขึ้นเป็นสองเท่า ซึ่งหมายความว่าเซิร์ฟเวอร์ต้องใช้แรงงานเพียง 50% ในการแลกเปลี่ยนข้อมูลเดียวกันกับผู้เล่นเมื่อเทียบกับก่อนหน้านี้ โดยต้องแก้ไขค่า "network-compression-threshold" ในไฟล์ "server.properties" ให้เป็น 512
เรามีบทความในคู่มือสำหรับเรื่องนี้เช่นกัน ดูได้ที่ นี่
Forge
คล้ายกับ Vanilla ตัวเลือกที่สามารถปรับแต่งบนเซิร์ฟเวอร์เองยังค่อนข้างจำกัด เพราะมีไฟล์คอนฟิกขนาดเล็กเท่านั้น แต่สามารถติดตั้งม็อดเสริมได้ ซึ่งช่วยให้เซิร์ฟเวอร์เบาลงได้บ้าง
การโหลดชิ้นส่วนล่วงหน้า (Preloading the chunks)
วิธีหนึ่งที่ช่วยลดภาระเซิร์ฟเวอร์คือการโหลดชิ้นส่วนล่วงหน้า เซิร์ฟเวอร์จะโหลดข้อมูลชิ้นส่วนที่บันทึกไว้ล่วงหน้าในช่วงที่ไม่มีผู้เล่นแทนที่จะสร้างและสร้างชิ้นส่วนใหม่ กระบวนการนี้ควรทำในช่วงกลางคืน โดยเริ่มก่อนนอน
ต้องติดตั้งม็อดเสริมสำหรับเรื่องนี้ ม็อดที่เหมาะสมสามารถดาวน์โหลดได้ที่ นี่
จากนั้นติดตั้งม็อดบนเซิร์ฟเวอร์ตามคำแนะนำของเรา
ก่อนรีสตาร์ทเซิร์ฟเวอร์ ควรตั้งค่า "max-tick-time" ใน "server.properties" เป็น "-1" เพื่อป้องกันเซิร์ฟเวอร์ล่ม และควรมี RAM อย่างน้อย 8-10 GB เพราะกระบวนการนี้ใช้ RAM มาก สามารถอัปเกรด RAM ชั่วคราวในช่วงกลางคืนแล้วลดลงหลังเสร็จสิ้น
โปรดทราบว่าม็อดที่กล่าวถึงอาจไม่เข้ากันกับเวอร์ชัน Forge ที่คุณใช้ และกระบวนการอาจแตกต่างหากใช้ม็อดอื่น
เมื่อเซิร์ฟเวอร์เริ่มทำงานพร้อมม็อดแล้ว ให้เปิดคอนโซล เราแนะนำให้สร้างขอบเขตโลกด้วยรัศมี 16,000 บล็อก โดยใช้คำสั่งต่อไปนี้ทีละคำสั่ง:
- worldborder center 0 0
- worldborder set 16000
ถ้าจำเป็น ให้เปลี่ยนพิกัดศูนย์กลางโลกด้วยคำสั่ง center เพื่อไม่ให้ "ตัด" โลกที่คุณสร้างไว้แล้ว
เมื่อกำหนดขอบเขตแล้ว สามารถเริ่มโหลดล่วงหน้าได้ด้วยคำสั่ง:
- pregen gen startWorldBorder
ตอนนี้ชิ้นส่วนทั้งหมดภายในขอบเขตจะถูกโหลดล่วงหน้าทีละชิ้น กระบวนการนี้อาจใช้เวลาถึง 8 ชั่วโมง ขึ้นอยู่กับจำนวนม็อดที่ติดตั้ง ความคืบหน้าจะแสดงในคอนโซลเป็นระยะๆ เมื่อเสร็จสิ้นก็จะแจ้งในคอนโซลด้วย!
ม็อดนี้ยังสามารถติดตั้งบนเซิร์ฟเวอร์หลังจากกระบวนการเสร็จสิ้นแล้ว มันจะช่วยปรับแต่งชิ้นส่วนระหว่างการใช้งานและทำงานแม้ไม่มีผู้เล่นบนเซิร์ฟเวอร์
การมองเห็น
มาตรการที่ใช้บ่อยคือการลดระยะการมองเห็น ค่าเริ่มต้นคือ 10 ชิ้นส่วน แต่หลายคนเล่นด้วยค่าที่น้อยกว่า เช่น 6-8 บางคนตั้งเกินไปถึง 32 ชิ้นส่วน ซึ่งทำให้เซิร์ฟเวอร์ต้องโหลดและประมวลผลชิ้นส่วนจำนวนมาก กินประสิทธิภาพ
ระยะการมองเห็นของเซิร์ฟเวอร์ Forge ปรับได้ในไฟล์ "server.properties" โดยแก้ไขค่า "view-distance" แนะนำให้ตั้งที่ 5-6 เพื่อไม่จำกัดประสบการณ์การเล่นมากเกินไป ช่วยลดภาระเซิร์ฟเวอร์ได้ถึง 50%
เรามีบทความในคู่มือสำหรับเรื่องนี้ ดูได้ที่ นี่
การบีบอัดข้อมูล
การแลกเปลี่ยนข้อมูลระหว่างเซิร์ฟเวอร์กับผู้เล่นเกิดขึ้นตลอดเวลา การเคลื่อนไหวและเหตุการณ์ต่างๆ ถูกส่งไปมา เพื่อให้การแลกเปลี่ยนข้อมูลนี้มีประสิทธิภาพมากขึ้น ให้ตั้งค่า "network-compression-threshold" ใน "server.properties" เป็น 512
ดูรายละเอียดเพิ่มเติมได้ที่ นี่
Bukkit
การมองเห็น
มาตรการที่ใช้บ่อยคือการลดระยะการมองเห็น ค่าเริ่มต้นคือ 10 ชิ้นส่วน แต่หลายคนเล่นด้วยค่าที่น้อยกว่า เช่น 6-8 บางคนตั้งเกินไปถึง 32 ชิ้นส่วน ซึ่งทำให้เซิร์ฟเวอร์ต้องโหลดและประมวลผลชิ้นส่วนจำนวนมาก กินประสิทธิภาพ
ระยะการมองเห็นของเซิร์ฟเวอร์ Forge ปรับได้ในไฟล์ "server.properties" โดยแก้ไขค่า "view-distance" แนะนำให้ตั้งที่ 5-6 เพื่อไม่จำกัดประสบการณ์การเล่นมากเกินไป ช่วยลดภาระเซิร์ฟเวอร์ได้ถึง 50%
เรามีบทความในคู่มือสำหรับเรื่องนี้ ดูได้ที่ นี่
การบีบอัดข้อมูล
การแลกเปลี่ยนข้อมูลระหว่างเซิร์ฟเวอร์กับผู้เล่นเกิดขึ้นตลอดเวลา การเคลื่อนไหวและเหตุการณ์ต่างๆ ถูกส่งไปมา เพื่อให้การแลกเปลี่ยนข้อมูลนี้มีประสิทธิภาพมากขึ้น ให้ตั้งค่า "network-compression-threshold" ใน "server.properties" เป็น 512
ดูรายละเอียดเพิ่มเติมได้ที่ นี่
ขีดจำกัดการเกิดม็อบ (Spawn-Limits)
ขั้นตอนนี้จะลดอัตราการเกิดม็อบทั่วไปบนเซิร์ฟเวอร์ลงเล็กน้อย ซึ่งแทบไม่ส่งผลแตกต่างที่สังเกตได้เมื่อเทียบกับค่าเริ่มต้น แต่บางครั้งในฟาร์มม็อบอาจทำงานไม่ตามแผน
เพื่อปรับตั้งค่านี้ ให้แก้ไขไฟล์ "bukkit.yml" ที่หัวข้อ "spawn-limits" โดยตั้งค่าดังนี้:
- monsters: 50 #ค่าเริ่มต้น: 70
- animals: 10 #ค่าเริ่มต้น: 15
- water-animals: 3 #ค่าเริ่มต้น: 5
- ambient: 4 #ค่าเริ่มต้น: 15
คุณสามารถปรับค่าเองได้ตามต้องการ แต่ค่าข้างต้นเป็นค่าเฉลี่ยที่ดีมาก
เพื่อปรับปรุงการเกิดม็อบเพิ่มเติม ให้เปลี่ยนค่า "monster-spawns" ใน "ticks-per" ในไฟล์ "bukkit.yml":
- monster-spawns: 2 #ค่าเริ่มต้น: 1
ถ้ามีปัญหาทั่วไปกับม็อบ (เช่นจากรายงาน timing) ค่านี้สามารถตั้งได้สูงสุดถึง 5 ควรสังเกตพฤติกรรมเซิร์ฟเวอร์กับแต่ละค่าเพื่อหาค่าที่เหมาะสมที่สุดสำหรับเซิร์ฟเวอร์ของคุณ
การประมวลผลชิ้นส่วน (Chunk-Processing)
Minecraft ใช้ระบบชิ้นส่วน (chunks) ซึ่งแต่ละชิ้นส่วนประกอบด้วยบล็อก 16x16 บล็อก เชื่อมต่อกันและแสดงโลกให้กับไคลเอนต์ เซิร์ฟเวอร์ทำงานกับชิ้นส่วนเหล่านี้และโหลดชิ้นส่วนที่ต้องการเข้า RAM ยิ่งโหลดและประมวลผลชิ้นส่วนมากเท่าไหร่ เซิร์ฟเวอร์ก็ต้องใช้พลังงานมากขึ้นเท่านั้น ซึ่งบางครั้งทำให้เซิร์ฟเวอร์ทำงานหนักเกินไป
เซิร์ฟเวอร์ที่ตั้งค่าเริ่มต้นจะไม่ปลดโหลดชิ้นส่วนที่โหลดแล้วเลย ทำให้ใช้ RAM หนักมากและต้องการ RAM จำนวนมาก ส่งผลให้ประสิทธิภาพเซิร์ฟเวอร์ลดลง
เพื่อให้เซิร์ฟเวอร์โหลดเฉพาะชิ้นส่วนที่จำเป็นเท่านั้น ให้ปรับตัวเลือกในไฟล์ "bukkit.yml" ภายใต้ "chunk-gc" ดังนี้:
- period-in-ticks: 300 #ค่าเริ่มต้น: 600
- load-threshold: 300 #ค่าเริ่มต้น: 0
ตัวเลือก "period-in-ticks" กำหนดช่วงเวลาที่ชิ้นส่วนจะถูกปลดโหลดเป็นวินาที หากต้องการสามารถลดค่านี้ได้อีก แต่ต้องระวังผลข้างเคียงที่ไม่พึงประสงค์ เช่น การเกิดลูป
ในกรณีลูป ชิ้นส่วนจะถูกปลดโหลด แต่ต้องการใช้อีกในไม่ช้า ทำให้เซิร์ฟเวอร์ต้องโหลดซ้ำและเสียเวลา ซึ่งจะเกิดซ้ำๆ ทำให้เซิร์ฟเวอร์ทำงานหนักกว่าการเก็บชิ้นส่วนนั้นไว้อีกนาทีหนึ่ง
Spigot
การมองเห็น
มาตรการที่ใช้บ่อยคือการลดระยะการมองเห็น ค่าเริ่มต้นคือ 10 ชิ้นส่วน แต่หลายคนเล่นด้วยค่าที่น้อยกว่า เช่น 6-8 บางคนตั้งเกินไปถึง 32 ชิ้นส่วน ซึ่งทำให้เซิร์ฟเวอร์ต้องโหลดและประมวลผลชิ้นส่วนจำนวนมาก กินประสิทธิภาพ
สำหรับเซิร์ฟเวอร์ Spigot ระยะการมองเห็นปรับได้ในไฟล์ "spigot.yml" โดยแก้ไขค่า "view-distance" แนะนำให้ตั้งที่ 5-6 เพื่อไม่จำกัดประสบการณ์การเล่นมากเกินไป ช่วยลดภาระเซิร์ฟเวอร์ได้ถึง 50%
ตามความชอบ คุณอาจตั้งค่าเป็น 4 ซึ่งช่วยลดแลคได้ดีเมื่อเล่นเซิร์ฟเวอร์ฟาร์มเวิลด์ที่ใช้เวอร์ชัน 1.13+
การบีบอัดข้อมูล
การแลกเปลี่ยนข้อมูลระหว่างเซิร์ฟเวอร์กับผู้เล่นเกิดขึ้นตลอดเวลา การเคลื่อนไหวและเหตุการณ์ต่างๆ ถูกส่งไปมา เพื่อให้การแลกเปลี่ยนข้อมูลนี้มีประสิทธิภาพมากขึ้น ให้ตั้งค่า "network-compression-threshold" ใน "server.properties" เป็น 512
ดูรายละเอียดเพิ่มเติมได้ที่ นี่
ขีดจำกัดการเกิดม็อบ (Spawn-Limits)
ลดอัตราการเกิดม็อบทั่วไปบนเซิร์ฟเวอร์ลงเล็กน้อย โดยแก้ไขไฟล์ "bukkit.yml" ที่หัวข้อ "spawn-limits":
- monsters: 50 #ค่าเริ่มต้น: 70
- animals: 10 #ค่าเริ่มต้น: 15
- water-animals: 3 #ค่าเริ่มต้น: 5
- ambient: 4 #ค่าเริ่มต้น: 15
คุณสามารถปรับค่าเองได้ตามต้องการ แต่ค่าข้างต้นเป็นค่าเฉลี่ยที่ดีมาก
ปรับค่า "monster-spawns" ใน "ticks-per" ในไฟล์ "bukkit.yml":
- monster-spawns: 2 #ค่าเริ่มต้น: 1
ถ้ามีปัญหาทั่วไปกับม็อบ ค่านี้สามารถตั้งได้สูงสุดถึง 5 ควรสังเกตพฤติกรรมเซิร์ฟเวอร์กับแต่ละค่าเพื่อหาค่าที่เหมาะสมที่สุด
การประมวลผลชิ้นส่วน (Chunk-Processing)
Minecraft ใช้ระบบชิ้นส่วน (chunks) ซึ่งแต่ละชิ้นส่วนประกอบด้วยบล็อก 16x16 บล็อก เชื่อมต่อกันและแสดงโลกให้กับไคลเอนต์ เซิร์ฟเวอร์ทำงานกับชิ้นส่วนเหล่านี้และโหลดชิ้นส่วนที่ต้องการเข้า RAM ยิ่งโหลดและประมวลผลชิ้นส่วนมากเท่าไหร่ เซิร์ฟเวอร์ก็ต้องใช้พลังงานมากขึ้นเท่านั้น ซึ่งบางครั้งทำให้เซิร์ฟเวอร์ทำงานหนักเกินไป
เซิร์ฟเวอร์ที่ตั้งค่าเริ่มต้นจะไม่ปลดโหลดชิ้นส่วนที่โหลดแล้วเลย ทำให้ใช้ RAM หนักมากและต้องการ RAM จำนวนมาก ส่งผลให้ประสิทธิภาพเซิร์ฟเวอร์ลดลง
ปรับตัวเลือกในไฟล์ "bukkit.yml" ภายใต้ "chunk-gc" ดังนี้:
- period-in-ticks: 300 #ค่าเริ่มต้น: 600
- load-threshold: 300 #ค่าเริ่มต้น: 0
ระวังผลข้างเคียงเช่นลูปที่ทำให้ชิ้นส่วนถูกโหลดและปลดโหลดซ้ำๆ
ระยะการเกิดม็อบ (Spawn-Range)
ลดระยะการเกิดม็อบจากผู้เล่นเพื่อป้องกันปัญหาเกี่ยวกับการเกิดม็อบ โดยแก้ไขไฟล์ "spigot.yml" ใน "world-settings":
- mob-spawn-range: 3 #ค่าเริ่มต้น: 4
ระยะการเปิดใช้งานเอนทิตี (Entity-Ranges)
ตั้งเวลาที่เอนทิตี เช่น สัตว์และม็อบ จะถูกเปิดใช้งาน เช่น การเคลื่อนไหวหรือการตรวจจับผู้เล่น โดยแก้ไขใน "spigot.yml" ที่ "entity-activation-range" ดังนี้:
- animals: 6 #ค่าเริ่มต้น: 32
- monsters: 16 #ค่าเริ่มต้น: 32
- misc: 2 #ค่าเริ่มต้น: 16
- water: 6 #ค่าเริ่มต้น: 6
- tick-inactive-villagers: true #ค่าเริ่มต้น: true
การปรับแต่งฟันเนล (Funnel-Optimizations)
ฟันเนลเป็นส่วนสำคัญของเกม แต่สำหรับเซิร์ฟเวอร์เป็นภาระหนัก เซิร์ฟเวอร์ต้องตรวจสอบฟันเนล 20 ครั้งต่อวินาทีว่ามีไอเท็มพร้อมหยิบหรือไม่ การย้ายไอเท็มระหว่างฟันเนลหรือกล่องก็ใช้ทรัพยากร
เพื่อปรับปรุง เราเพิ่มช่วงเวลาที่เซิร์ฟเวอร์ตรวจสอบเป็นทุก 3 วินาที โดยไม่เปลี่ยนอัตราการโอนย้าย แต่บางครั้งนาฬิกาเรดสโตนที่สร้างด้วยฮอปเปอร์อาจทำงานผิดปกติ
แก้ไขใน "spigot.yml":
- hopper-transfer: 24 #ค่าเริ่มต้น: 8
- hopper-check: 24 #ค่าเริ่มต้น: 8
- hopper-amount: 3 #ค่าเริ่มต้น: 1
การชนกัน (Collisions)
ตั้งแต่ Minecraft 1.9 มีระบบชนกันที่ไม่ให้ผู้เล่นยืนทับกันได้ เรากำหนดความถี่ที่เอนทิตีชนกันได้ โดยเฉพาะในฟาร์มม็อบที่มีม็อบจำนวนมากในพื้นที่แคบ อาจทำให้เซิร์ฟเวอร์ทำงานหนัก
แก้ไขใน "spigot.yml":
- max-entity-collisions: 1 #ค่าเริ่มต้น: 8
การตั้งค่านี้ไม่ส่งผลกับผู้เล่น แต่ใช้กับม็อบเท่านั้น
รัศมีการรวม (Merge-Radius)
รัศมีการรวมกำหนดว่าไอเท็มและ XP ใดจะถูกรวมกัน ทำให้เซิร์ฟเวอร์ประมวลผลเอนทิตีน้อยลง โดยเฉพาะเซิร์ฟเวอร์ที่มีไอเท็มจำนวนมากบนพื้น การเพิ่มรัศมีนี้ช่วยได้ แต่ต้องหาค่ากลางที่เหมาะสมเพื่อไม่ให้เกิดแลคจากการตรวจสอบพื้นที่กว้างเกินไป
แก้ไขใน "spigot.yml" ที่ "merge-radius":
- item: 4.0 #ค่าเริ่มต้น: 2.5
- exp: 6.0 #ค่าเริ่มต้น: 3.0
ไม่ควรตั้งค่าสูงกว่า 8 เพื่อป้องกันแลคที่กล่าวมา
Paper Spigot
การมองเห็น
ลดระยะการมองเห็นเหมือนกับ Spigot โดยแก้ไขค่า "view-distance" ใน "spigot.yml" แนะนำตั้งที่ 5-6 เพื่อช่วยลดภาระเซิร์ฟเวอร์ได้ถึง 50%
ตามความชอบ อาจตั้งเป็น 4 เพื่อช่วยลดแลคในเซิร์ฟเวอร์ฟาร์มเวิลด์เวอร์ชัน 1.13+
การบีบอัดข้อมูล
ตั้งค่า "network-compression-threshold" ใน "server.properties" เป็น 512 เพื่อเพิ่มประสิทธิภาพการแลกเปลี่ยนข้อมูล
ดูรายละเอียดเพิ่มเติมได้ที่ นี่
ขีดจำกัดการเกิดม็อบ (Spawn-Limits)
แก้ไขไฟล์ "bukkit.yml" ที่ "spawn-limits":
- monsters: 50 #ค่าเริ่มต้น: 70
- animals: 10 #ค่าเริ่มต้น: 15
- water-animals: 3 #ค่าเริ่มต้น: 5
- ambient: 4 #ค่าเริ่มต้น: 15
ปรับค่าเองได้ตามต้องการ แต่ค่าข้างต้นเป็นค่าเฉลี่ยที่ดี
ปรับค่า "monster-spawns" ใน "ticks-per":
- monster-spawns: 2 #ค่าเริ่มต้น: 1
การประมวลผลชิ้นส่วน (Chunk-Processing)
แก้ไขใน "bukkit.yml" ภายใต้ "chunk-gc":
- period-in-ticks: 300 #ค่าเริ่มต้น: 600
- load-threshold: 300 #ค่าเริ่มต้น: 0
ระยะการเกิดม็อบ (Spawn-Range)
แก้ไขใน "spigot.yml" ที่ "world-settings":
- mob-spawn-range: 3 #ค่าเริ่มต้น: 4
ตัวสร้างม็อบ (Mob-Spawner)
บนเซิร์ฟเวอร์แบบ city build ใช้ตัวสร้างม็อบจำนวนมาก ซึ่งอาจทำให้เกิดปัญหา ตัวเลือกนี้ปรับพฤติกรรมการทำงานของตัวสร้างม็อบให้ทำงานถี่น้อยลง
แก้ไขใน "paper.yml":
- mob-spawner-tick-rate: 3 #ค่าเริ่มต้น: 1
ค่านี้ไม่เปลี่ยนพฤติกรรมมากและไม่กระทบการเล่นเกม
ระยะการเปิดใช้งานเอนทิตี (Entity-Ranges)
แก้ไขใน "spigot.yml" ที่ "entity-activation-range":
- animals: 6 #ค่าเริ่มต้น: 32
- monsters: 16 #ค่าเริ่มต้น: 32
- misc: 2 #ค่าเริ่มต้น: 16
- water: 6 #ค่าเริ่มต้น: 6
- tick-inactive-villagers: true #ค่าเริ่มต้น: true
การปรับแต่งฟันเนล (Funnel-Optimization)
แก้ไขใน "spigot.yml":
- hopper-transfer: 24 #ค่าเริ่มต้น: 8
- hopper-check: 24 #ค่าเริ่มต้น: 8
- hopper-amount: 3 #ค่าเริ่มต้น: 1
ตรวจสอบให้แน่ใจว่า "use-hopper-check" ตั้งเป็น "true" ใน "paper.yml"
การชนกัน (Collisions)
แก้ไขใน "spigot.yml":
- max-entity-collisions: 1 #ค่าเริ่มต้น: 8
รัศมีการรวม (Merge-Radius)
แก้ไขใน "spigot.yml" ที่ "merge-radius":
- item: 4.0 #ค่าเริ่มต้น: 2.5
- exp: 6.0 #ค่าเริ่มต้น: 3.0
ไม่ควรตั้งค่าสูงกว่า 8 เพื่อป้องกันแลค
การระเบิด (Explosions)
Paper Spigot ปรับปรุงการจัดการการระเบิดเพื่อให้เซิร์ฟเวอร์ทำงานดีขึ้น
แก้ไขใน "paper.yml":
- optimize-explosions: true #ค่าเริ่มต้น: false
กล่อง (Chests)
ถ้ามีแมวนั่งบนกล่อง จะเปิดไม่ได้ เซิร์ฟเวอร์ต้องตรวจสอบแมวในรัศมี ซึ่งใช้เวลามากทุกครั้งที่เปิดกล่อง
ปิดฟีเจอร์นี้ได้โดยแก้ไข:
- disable-chest-cat-detection: true #ค่าเริ่มต้น: false
อินเวนทอรี (Inventories)
ตั้งจำนวน tick ที่เซิร์ฟเวอร์จะอัปเดตอินเวนทอรี เช่น กล่องหรือโต๊ะคราฟต์
แก้ไขใน "paper.yml":
- container-update-tick-rate: 3 #ค่าเริ่มต้น: 1
ไม่ควรตั้งเกิน 5 เพราะอาจทำให้อินเวนทอรีมีบั๊ก ในโหมดเกมอย่าง SurvivalGames ควรตั้งเป็น 1
การอัปเดตแสง (Light-Updates)
Paper Spigot มีตัวเลือกให้ทำการอัปเดตแสงแบบอะซิงค์ (async) เพื่อไม่ให้เซิร์ฟเวอร์หยุดชะงัก
แก้ไขใน "paper.yml":
- queue-light-updates: true #ค่าเริ่มต้น: false
การบันทึกข้อมูลชิ้นส่วน (Saving Chunk Data)
การเปลี่ยนแปลงในชิ้นส่วนจะถูกเก็บไว้ใน RAM ก่อนเขียนลงดิสก์บ่อยครั้ง ซึ่งอาจทำให้แลคเมื่อเซิร์ฟเวอร์บันทึกข้อมูลจำนวนมาก
ลดจำนวนชิ้นส่วนสูงสุดที่บันทึกต่อ tick ใน "paper.yml":
- max-auto-save-chunks-per-tick: 10 #ค่าเริ่มต้น: 24
เรดสโตน (Redstone)
เรดสโตนมักใช้ในวงจรขนาดใหญ่ ซึ่งบนเซิร์ฟเวอร์สาธารณะมักเป็นจุดอ่อนที่ทำให้เกิดแลค Paper Spigot มีวิธีประมวลผลเรดสโตนที่เร็วขึ้นและยังคงฟังก์ชันเหมือน Vanilla
แก้ไขใน "paper.yml":
- use-faster-eigencraft-redstone: true #ค่าเริ่มต้น: false
ระวัง! ในบางสถานการณ์อาจเปลี่ยนพฤติกรรมของเรดสโตนได้มาก!