ماينكرافت: تحسين أداء خادم الألعاب
تم إنشاء هذا الدليل باستخدام المنتجات التالية:
(قد تختلف التفاصيل مع المنتجات من مزودين مختلفين ولكن المفاهيم الرئيسية تظل كما هي)
ماذا يحدث بالضبط أثناء التحسين؟
التحسين نقطة مهمة لخوادم ألعاب ماينكرافت حتى تعمل بسلاسة ويجب أن تخصص وقت كافي لهذا على خادم عام. فقط مع الكثير من الوقت والاختبارات يمكن تحقيق أفضل نتيجة. لذلك، هذه الوثائق ليست بالضرورة لتُتبع حرفيًا، بل هي مساعدة لتوجيهك في الاتجاه الصحيح.
في معظم الحالات، يقوم التحسين بتغيير عدد كبير من الإعدادات على الخوادم، مما يغير في بعض الأحيان سلوك الخادم نفسه بشكل كبير. من بين أمور أخرى، يتم تقليل بعض الإعدادات، مما يخفف العبء عن الخادم وبالتالي يمكن أن يوفر أداءً أفضل. لكن، حتى لا يتأثر تجربة اللعب العامة بشكل كبير، يجب دائمًا إيجاد التوازن المثالي هنا.
Vanilla
خيارات تحسين خادم Vanilla للأسف محدودة جدًا، لأنه لا توجد سوى بعض خيارات الإعداد المتاحة. نحاول منح خادم Vanilla قوة أكبر قليلاً باتخاذ الإجراءات التالية:
الرؤية
إجراء يُتخذ كثيرًا هو تقليل مدى الرؤية. المدى الافتراضي للرؤية هو 10 chunks، لكن العديد من اللاعبين يلعبون بعدد أقل بكثير، مثل 6-8. بعض اللاعبين يبالغون في عدد الـ chunks وأحيانًا يضبطونها على 32 chunks كمثال، مما يعني أن الخادم يجب أن يحمل ويعالج كل هذه الـ chunks، وهذا يستهلك الكثير من الأداء.
مع خادم Vanilla، يمكن تعديل مدى الرؤية في ملف الإعداد "server.properties"، حيث يجب تعديل القيمة "view-distance". لتجنب تقييد تجربة اللعب كثيرًا، يُنصح بضبط هذه القيمة على 5-6، مما يخفف العبء عن الخادم حتى 50%. لدينا بالفعل مدخل في وثائقنا لهذا، يمكن العثور عليه هنا.
ضغط البيانات
يوجد تبادل دائم بين الخادم واللاعبين المتصلين. يتم إرسال حركات اللاعبين إلى الخادم، ثم يرسل الخادم هذه البيانات إلى جميع اللاعبين الآخرين. كما أن أفعال اللاعبين أو الأحداث في العالم، مثل الانفجارات كمثال، جزء من البيانات التي تُنقل مرارًا وتكرارًا.
لجعل هذا التبادل أكثر كفاءة، يمكن مضاعفة حجم البيانات المضغوطة، مما يعني أن الخادم يحتاج فقط إلى بذل 50% من الجهد لتبادل نفس البيانات مع اللاعبين مقارنة بالسابق. للقيام بذلك، يجب تعديل القيمة "network-compression-threshold" في ملف "server.properties". يجب ضبط القيمة على 512 هنا. لدينا أيضًا مدخل في وثائقنا لهذا، يمكن العثور عليه هنا.
Forge
مماثل لـ Vanilla، الخيارات التي يمكن تعديلها على الخادم نفسه محدودة بعض الشيء، حيث تتوفر ملفات إعداد صغيرة فقط. لكن يمكن تثبيت مودات إضافية، مما يعني أن الخادم يمكن أن يُخفف بعض الشيء.
تحميل الـ chunks مسبقًا
إحدى الطرق لتخفيف العبء عن الخادم هي تحميل الـ chunks مسبقًا. عندها يحتاج الخادم فقط لتحميل بيانات الـ chunks المحفوظة أثناء التشغيل لاحقًا مع اللاعبين، وليس إنشاء وتوليد كل الـ chunks. من الأفضل ترك هذه العملية تعمل طوال الليل، تبدأها مساءً.
يجب تثبيت مود إضافي لهذا. يمكن تثبيت مود مناسب جدًا هنا. يمكن تثبيت المود على الخادم بشكل عادي كما هو موضح في تعليماتنا.
قبل إعادة تشغيل الخادم، تأكد من أن "max-tick-time" في "server.properties" مضبوط على "-1". وإلا قد يتعطل الخادم. يُنصح أيضًا بتوفر 8-10 جيجابايت على الأقل من RAM، لأن هذه العملية تتطلب الكثير من الذاكرة. يمكن ترقية الذاكرة مؤقتًا طوال الليل ثم تخفيضها بعد الانتهاء.
لاحظ أن المود المذكور قد لا يكون متوافقًا مع نسخة Forge التي تستخدمها وقد تختلف العملية إذا كنت تستخدم مودًا مختلفًا.
بمجرد تشغيل الخادم مع المود، يجب فتح الكونسول. نوصي بإنشاء حدود للعالم بنصف قطر 16,000 بلوك. لتنفيذ ذلك، يجب تنفيذ الأوامر التالية بالتسلسل:
- worldborder center 0 0
- worldborder set 16000
إذا لزم الأمر، استبدل الإحداثيات بمركز عالمك الخاص باستخدام أمر center حتى لا "تقطع" عالمك (الذي قد يكون قد بُني بالفعل).
بمجرد تعيين الحدود، يمكن بدء التحميل المسبق الفعلي. لتنفيذ ذلك، نفذ الأمر التالي:
- pregen gen startWorldBorder
الآن يتم تحميل كل الـ chunks داخل الحدود واحدًا تلو الآخر. قد تستغرق هذه العملية حتى 8 ساعات حسب عدد المودات المثبتة. يتم عرض تقدم العملية دائمًا في الكونسول من خلال رسائل معلومات دورية. وعندما تنتهي العملية، يتم أيضًا إعلامك في الكونسول!
يمكن تثبيت المود على الخادم حتى بعد انتهاء هذه العملية. سيستمر في تحسين الـ chunks أثناء التشغيل وسيعمل حتى عندما لا يكون هناك لاعب على الخادم.
الرؤية
إجراء يُتخذ كثيرًا هو تقليل مدى الرؤية. المدى الافتراضي للرؤية هو 10 chunks، لكن العديد من اللاعبين يلعبون بعدد أقل بكثير، مثل 6-8. بعض اللاعبين يبالغون في عدد الـ chunks وأحيانًا يضبطونها على 32 chunks كمثال، مما يعني أن الخادم يجب أن يحمل ويعالج كل هذه الـ chunks، وهذا يستهلك الكثير من الأداء.
يمكن تعديل مدى الرؤية في خادم Forge في ملف "server.properties"، حيث يجب تعديل القيمة "view-distance". لتجنب تقييد تجربة اللعب كثيرًا، يُنصح بضبط هذه القيمة على 5-6، مما يخفف العبء عن الخادم حتى 50%. لدينا بالفعل مدخل في وثائقنا لهذا، يمكن العثور عليه هنا.
ضغط البيانات
يوجد تبادل دائم بين الخادم واللاعبين المتصلين. يتم إرسال حركات اللاعبين إلى الخادم، ثم يرسل الخادم هذه البيانات إلى جميع اللاعبين الآخرين. كما أن أفعال اللاعبين أو الأحداث في العالم، مثل الانفجارات كمثال، جزء من البيانات التي تُنقل مرارًا وتكرارًا.
لجعل هذا التبادل أكثر كفاءة، يمكن مضاعفة حجم البيانات المضغوطة، مما يعني أن الخادم يحتاج فقط إلى بذل 50% من الجهد لتبادل نفس البيانات مع اللاعبين مقارنة بالسابق. للقيام بذلك، يجب تعديل القيمة "network-compression-threshold" في ملف "server.properties". يجب ضبط القيمة على 512 هنا. لدينا أيضًا مدخل في وثائقنا لهذا، يمكن العثور عليه هنا.
Bukkit
الرؤية
إجراء يُتخذ كثيرًا هو تقليل مدى الرؤية. المدى الافتراضي للرؤية هو 10 chunks، لكن العديد من اللاعبين يلعبون بعدد أقل بكثير، مثل 6-8. بعض اللاعبين يبالغون في عدد الـ chunks وأحيانًا يضبطونها على 32 chunks كمثال، مما يعني أن الخادم يجب أن يحمل ويعالج كل هذه الـ chunks، وهذا يستهلك الكثير من الأداء.
يمكن تعديل مدى الرؤية في خادم Forge في ملف "server.properties"، حيث يجب تعديل القيمة "view-distance". لتجنب تقييد تجربة اللعب كثيرًا، يُنصح بضبط هذه القيمة على 5-6، مما يخفف العبء عن الخادم حتى 50%. لدينا بالفعل مدخل في وثائقنا لهذا، يمكن العثور عليه هنا.
ضغط البيانات
يوجد تبادل دائم بين الخادم واللاعبين المتصلين. يتم إرسال حركات اللاعبين إلى الخادم، ثم يرسل الخادم هذه البيانات إلى جميع اللاعبين الآخرين. كما أن أفعال اللاعبين أو الأحداث في العالم، مثل الانفجارات كمثال، جزء من البيانات التي تُنقل مرارًا وتكرارًا.
لجعل هذا التبادل أكثر كفاءة، يمكن مضاعفة حجم البيانات المضغوطة، مما يعني أن الخادم يحتاج فقط إلى بذل 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
إذا كان هناك مشكلة عامة مع الوحوش (كما يمكن تحديدها في تقرير التوقيت)، يمكن ضبط القيمة حتى 5. يجب مراقبة سلوك الخادم مع كل قيمة لإيجاد الأفضل لخادمك.
معالجة الـ Chunks
يعمل ماينكرافت باستخدام ما يسمى بالـ chunks. الـ chunk يتكون دائمًا من 16x16 بلوك، والتي تُجمع معًا وتمثل العالم بصريًا للعميل. لذلك، يعمل الخادم فقط مع الـ chunks ويحمّل الـ chunks المطلوبة في الذاكرة RAM. كلما زاد عدد الـ chunks المحملة والمعالجة باستمرار من قبل الخادم، زاد الجهد المطلوب من الخادم، مما قد يثقل الخادم في بعض الأماكن.
الخوادم بالإعدادات الافتراضية لا تقوم أبدًا بإلغاء تحميل الـ chunks المحملة، مما يعني أن الذاكرة RAM تُستخدم بشكل مكثف جدًا في بعض الأماكن ويُطلب منها كمية هائلة. بالطبع، هذا يقلل من أداء الخادم بشكل كبير لأنه يجب معالجة المزيد والمزيد.
لضمان أن الخادم يحمل فقط الـ chunks المطلوبة حاليًا، يجب تعديل الخيارات التالية في ملف "bukkit.yml" تحت "chunk-gc":
- period-in-ticks: 300 #الافتراضي: 600
- load-threshold: 300 #الافتراضي: 0
تحدد خيار "period-in-ticks" الفواصل الزمنية بالثواني التي يجب عندها إلغاء تحميل الـ chunks. يمكن تقليل هذه القيمة أكثر إذا رغبت، لكن يجب الانتباه لاحتمال حدوث تأثير غير مرغوب: حلقة مستمرة
في حالة الحلقة، يتم إلغاء تحميل الـ chunk، ثم يحتاج الخادم إلى تحميله مرة أخرى بعد فترة قصيرة، مما يستهلك أداء ووقتًا إضافيًا. هذا يتكرر مرارًا، مما يثقل الخادم أكثر من ترك الـ chunks محملة لفترة أطول.
Spigot
الرؤية
إجراء يُتخذ كثيرًا هو تقليل مدى الرؤية. المدى الافتراضي للرؤية هو 10 chunks، لكن العديد من اللاعبين يلعبون بعدد أقل بكثير، مثل 6-8. بعض اللاعبين يبالغون في عدد الـ chunks وأحيانًا يضبطونها على 32 chunks كمثال، مما يعني أن الخادم يجب أن يحمل ويعالج كل هذه الـ chunks، وهذا يستهلك الكثير من الأداء.
مع خادم spigot، يمكن تعديل مدى الرؤية في ملف "spigot.yml"، حيث يجب تعديل القيمة "view-distance". لتجنب تقييد تجربة اللعب كثيرًا، يُنصح بضبط هذه القيمة على 5-6، مما يخفف العبء عن الخادم حتى 50%.
حسب تفضيلك، يمكن أيضًا ضبط القيمة على 4، مما يساعد بشكل جيد ضد التقطيع عند تشغيل خوادم عوالم المزارع على نسخة 1.13+
ضغط البيانات
يوجد تبادل دائم بين الخادم واللاعبين المتصلين. يتم إرسال حركات اللاعبين إلى الخادم، ثم يرسل الخادم هذه البيانات إلى جميع اللاعبين الآخرين. كما أن أفعال اللاعبين أو الأحداث في العالم، مثل الانفجارات كمثال، جزء من البيانات التي تُنقل مرارًا وتكرارًا.
لجعل هذا التبادل أكثر كفاءة، يمكن مضاعفة حجم البيانات المضغوطة، مما يعني أن الخادم يحتاج فقط إلى بذل 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
إذا كان هناك مشكلة عامة مع الوحوش (كما يمكن تحديدها في تقرير التوقيت)، يمكن ضبط القيمة حتى 5. يجب مراقبة سلوك الخادم مع كل قيمة لإيجاد الأفضل لخادمك.
معالجة الـ Chunks
يعمل ماينكرافت باستخدام ما يسمى بالـ chunks. الـ chunk يتكون دائمًا من 16x16 بلوك، والتي تُجمع معًا وتمثل العالم بصريًا للعميل. لذلك، يعمل الخادم فقط مع الـ chunks ويحمّل الـ chunks المطلوبة في الذاكرة RAM. كلما زاد عدد الـ chunks المحملة والمعالجة باستمرار من قبل الخادم، زاد الجهد المطلوب من الخادم، مما قد يثقل الخادم في بعض الأماكن.
الخوادم بالإعدادات الافتراضية لا تقوم أبدًا بإلغاء تحميل الـ chunks المحملة، مما يعني أن الذاكرة RAM تُستخدم بشكل مكثف جدًا في بعض الأماكن ويُطلب منها كمية هائلة. بالطبع، هذا يقلل من أداء الخادم بشكل كبير لأنه يجب معالجة المزيد والمزيد.
لضمان أن الخادم يحمل فقط الـ chunks المطلوبة حاليًا، يجب تعديل الخيارات التالية في ملف "bukkit.yml" تحت "chunk-gc":
- period-in-ticks: 300 #الافتراضي: 600
- load-threshold: 300 #الافتراضي: 0
تحدد خيار "period-in-ticks" الفواصل الزمنية بالثواني التي يجب عندها إلغاء تحميل الـ chunks. يمكن تقليل هذه القيمة أكثر إذا رغبت، لكن يجب الانتباه لاحتمال حدوث تأثير غير مرغوب: حلقة مستمرة
في حالة الحلقة، يتم إلغاء تحميل الـ chunk، ثم يحتاج الخادم إلى تحميله مرة أخرى بعد فترة قصيرة، مما يستهلك أداء ووقتًا إضافيًا. هذا يتكرر مرارًا، مما يثقل الخادم أكثر من ترك الـ chunks محملة لفترة أطول.
مدى الظهور (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
تحسينات القمع (Funnels)
القمع جزء مهم جدًا في لعبة ماينكرافت. لكن للخوادم هو سم قاتل! لكل قمع معين، يجب على الخادم التحقق 20 مرة في الثانية إذا كان هناك عنصر جاهز للالتقاط. نقل العناصر من قمع إلى آخر أو إلى صندوق يستهلك أيضًا جهدًا ثمينًا!
لتحسين الأمر، نزيد الفواصل الزمنية التي يجب أن ينفذ فيها الخادم هذه العمليات. بالقيم المستخدمة هنا، يتم تنفيذ وفحص هذه العملية كل 3 ثوانٍ. معدلات النقل لا تتغير. لكن قد لا تعمل ساعات الريدستون التي تم إنشاؤها بالقمع بشكل صحيح.
لتعديل الإعدادات، يجب تعديل القيم التالية في ملف "spigot.yml":
- hopper-transfer: 24 #الافتراضي: 8
- hopper-check: 24 #الافتراضي: 8
- hopper-amount: 3 #الافتراضي: 1
التصادمات
منذ نسخة ماينكرافت 1.9، هناك تصادمات، حيث لا يمكن للاعب أن يقف داخل لاعب آخر. هنا نحدد عدد مرات تصادم الكيانات بشكل عام. خاصة في مزارع الوحوش، حيث يلتقي العديد من الوحوش في مساحة ضيقة، قد يثقل هذا الخادم.
لتعديل الإعداد، يجب تعديل القيمة التالية في "spigot.yml":
- max-entity-collisions: 1 #الافتراضي: 8
بما أن التصادمات ليس لها تأثير حقيقي على الوحوش، يمكن تقليل هذا الإعداد هنا. هذه القيمة لا تُستخدم للاعبين، فقط للوحوش!
نصف قطر الدمج (Merge-Radius)
نصف قطر الدمج يحدد أي العناصر وXP يتم دمجها، مما يعني أن الخادم يعالج كيانات أقل. خاصة في الخوادم التي يوجد بها العديد من العناصر على الأرض، يمكن أن يكون لهذا تأثير إيجابي على اللاعبين إذا زاد هذا النطاق. هنا أيضًا القاعدة هي إيجاد قيمة وسط جيدة، وإلا سيحدث تأثير تقطيع حيث يجب على الخادم فحص نطاق أكبر، مما يتطلب طاقة أكثر!
لتعديل الإعداد، يجب تعديل القيم التالية تحت "merge-radius" في "spigot.yml":
- item: 4.0 #الافتراضي 2.5
- exp: 6.0 #الافتراضي: 3.0
لا يجب ضبط القيم هنا أعلى من 8، وإلا قد يحدث تأثير التقطيع المذكور أعلاه!
Paper Spigot
الرؤية
إجراء يُتخذ كثيرًا هو تقليل مدى الرؤية. المدى الافتراضي للرؤية هو 10 chunks، لكن العديد من اللاعبين يلعبون بعدد أقل بكثير، مثل 6-8. بعض اللاعبين يبالغون في عدد الـ chunks وأحيانًا يضبطونها على 32 chunks كمثال، مما يعني أن الخادم يجب أن يحمل ويعالج كل هذه الـ chunks، وهذا يستهلك الكثير من الأداء.
مع خادم (paper) spigot، يمكن تعديل مدى الرؤية في ملف "spigot.yml"، حيث يجب تعديل القيمة "view-distance". لتجنب تقييد تجربة اللعب كثيرًا، يُنصح بضبط هذه القيمة على 5-6، مما يخفف العبء عن الخادم حتى 50%.
حسب تفضيلك، يمكن أيضًا ضبط القيمة على 4، مما يساعد بشكل جيد ضد التقطيع عند تشغيل خوادم عوالم المزارع على نسخة 1.13+
ضغط البيانات
يوجد تبادل دائم بين الخادم واللاعبين المتصلين. يتم إرسال حركات اللاعبين إلى الخادم، ثم يرسل الخادم هذه البيانات إلى جميع اللاعبين الآخرين. كما أن أفعال اللاعبين أو الأحداث في العالم، مثل الانفجارات كمثال، جزء من البيانات التي تُنقل مرارًا وتكرارًا.
لجعل هذا التبادل أكثر كفاءة، يمكن مضاعفة حجم البيانات المضغوطة، مما يعني أن الخادم يحتاج فقط إلى بذل 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
إذا كان هناك مشكلة عامة مع الوحوش (كما يمكن تحديدها في تقرير التوقيت)، يمكن ضبط القيمة حتى 5. يجب مراقبة سلوك الخادم مع كل قيمة لإيجاد الأفضل لخادمك.
معالجة الـ Chunks
يعمل ماينكرافت باستخدام ما يسمى بالـ chunks. الـ chunk يتكون دائمًا من 16x16 بلوك، والتي تُجمع معًا وتمثل العالم بصريًا للعميل. لذلك، يعمل الخادم فقط مع الـ chunks ويحمّل الـ chunks المطلوبة في الذاكرة RAM. كلما زاد عدد الـ chunks المحملة والمعالجة باستمرار من قبل الخادم، زاد الجهد المطلوب من الخادم، مما قد يثقل الخادم في بعض الأماكن.
الخوادم بالإعدادات الافتراضية لا تقوم أبدًا بإلغاء تحميل الـ chunks المحملة، مما يعني أن الذاكرة RAM تُستخدم بشكل مكثف جدًا في بعض الأماكن ويُطلب منها كمية هائلة. بالطبع، هذا يقلل من أداء الخادم بشكل كبير لأنه يجب معالجة المزيد والمزيد.
لضمان أن الخادم يحمل فقط الـ chunks المطلوبة حاليًا، يجب تعديل الخيارات التالية في ملف "bukkit.yml" تحت "chunk-gc":
- period-in-ticks: 300 #الافتراضي: 600
- load-threshold: 300 #الافتراضي: 0
تحدد خيار "period-in-ticks" الفواصل الزمنية بالثواني التي يجب عندها إلغاء تحميل الـ chunks. يمكن تقليل هذه القيمة أكثر إذا رغبت، لكن يجب الانتباه لاحتمال حدوث تأثير غير مرغوب: حلقة مستمرة
في حالة الحلقة، يتم إلغاء تحميل الـ chunk، ثم يحتاج الخادم إلى تحميله مرة أخرى بعد فترة قصيرة، مما يستهلك أداء ووقتًا إضافيًا. هذا يتكرر مرارًا، مما يثقل الخادم أكثر من ترك الـ chunks محملة لفترة أطول.
مدى الظهور (Spawn-Range)
يمكن للوحوش الظهور دائمًا من اللاعبين بفواصل معينة. هنا نخفض هذا المعدل قليلاً لتجنب مشاكل ظهور الوحوش. هذا الإعداد مهم جدًا، حيث تم تعديل بعض إعدادات الظهور التي شرحناها أعلاه.
نغير الإعدادات التالية في ملف "spigot.yml" ضمن "world-settings":
- mob-spawn-range: 3 #الافتراضي: 4
مولد الوحوش (Mob-Spawner)
خاصة في خوادم البناء الحضري، تُستخدم المولدات كثيرًا وأحيانًا بأعداد كبيرة. تقوم المولدات بإنشاء المزيد والمزيد من الوحوش على الخادم، مما قد يسبب مشاكل كثيرة.
يعدل هذا الخيار سلوك ظهور المولد بحيث يقوم الخادم بتنشيط المولد بفواصل زمنية قصيرة. لتعديل ذلك، يجب تعديل القيمة التالية في "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
تحسينات القمع (Funnels)
القمع جزء مهم جدًا في لعبة ماينكرافت. لكن للخوادم هو سم قاتل! لكل قمع معين، يجب على الخادم التحقق 20 مرة في الثانية إذا كان هناك عنصر جاهز للالتقاط. نقل العناصر من قمع إلى آخر أو إلى صندوق يستهلك أيضًا جهدًا ثمينًا!
لتحسين الأمر، نزيد الفواصل الزمنية التي يجب أن ينفذ فيها الخادم هذه العمليات. بالقيم المستخدمة هنا، يتم تنفيذ وفحص هذه العملية كل 3 ثوانٍ. معدلات النقل لا تتغير. لكن قد لا تعمل ساعات الريدستون التي تم إنشاؤها بالقمع بشكل صحيح.
لتعديل الإعدادات، يجب تعديل القيم التالية في ملف "spigot.yml":
- hopper-transfer: 24 #الافتراضي: 8
- hopper-check: 24 #الافتراضي: 8
- hopper-amount: 3 #الافتراضي: 1
تأكد من أن القيمة "use-hopper-check" مضبوطة على "true" في ملف "paper.yml"!
التصادمات
منذ نسخة ماينكرافت 1.9، هناك تصادمات، حيث لا يمكن للاعب أن يقف داخل لاعب آخر. هنا نحدد عدد مرات تصادم الكيانات بشكل عام. خاصة في مزارع الوحوش، حيث يلتقي العديد من الوحوش في مساحة ضيقة، قد يثقل هذا الخادم.
لتعديل الإعداد، يجب تعديل القيمة التالية في "spigot.yml":
- max-entity-collisions: 1 #الافتراضي: 8
بما أن التصادمات ليس لها تأثير حقيقي على الوحوش، يمكن تقليل هذا الإعداد هنا. هذه القيمة لا تُستخدم للاعبين، فقط للوحوش!
نصف قطر الدمج (Merge-Radius)
نصف قطر الدمج يحدد أي العناصر وXP يتم دمجها، مما يعني أن الخادم يعالج كيانات أقل. خاصة في الخوادم التي يوجد بها العديد من العناصر على الأرض، يمكن أن يكون لهذا تأثير إيجابي على اللاعبين إذا زاد هذا النطاق. هنا أيضًا القاعدة هي إيجاد قيمة وسط جيدة، وإلا سيحدث تأثير تقطيع حيث يجب على الخادم فحص نطاق أكبر، مما يتطلب طاقة أكثر!
لتعديل الإعداد، يجب تعديل القيم التالية تحت "merge-radius" في "spigot.yml":
- item: 4.0 #الافتراضي 2.5
- exp: 6.0 #الافتراضي: 3.0
لا يجب ضبط القيم هنا أعلى من 8، وإلا قد يحدث تأثير التقطيع المذكور أعلاه!
الانفجارات
في Paper Spigot، تمت إعادة برمجة العديد من أجزاء خوادم ماينكرافت لجعل الخادم يعمل بشكل أفضل. وهذا يشمل الانفجارات! هنا، يتعامل البرنامج مع الانفجارات بشكل أفضل لتجنب التقطعات الكبيرة على الخادم.
لتعديل ذلك، يجب تعديل القيمة التالية في ملف "paper.yml":
- optimize-explosions: true #الافتراضي: false
الصناديق (Chests)
حتى مع الصناديق هناك شيء يمكن تحسينه! إذا كانت قطة جالسة على الصندوق، لا يمكن فتحه. لكي يتحقق الخادم من ذلك، يجب أن يمر عبر كل الوحوش في نطاق معين ويتحقق مما إذا كانت إحدى هذه الوحوش جالسة على الصندوق، وهذا مكلف جدًا ويحدث في كل مرة يُفتح فيها صندوق!
يمكن تعطيل هذا الخيار بسهولة بالتعديل التالي:
- disable-chest-cat-detection: true #الافتراضي: false
المخازن (Inventories)
المخزن يُستخدم كثيرًا، لكن المخزن ليس مجرد مخزن. كمثال، الصندوق أو طاولة العمل أيضًا مخازن. مع هذا التغيير، يمكنك تحسين أداء الخادم بشكل خفي! هنا نحدد فقط عدد الـ ticks بعد التي يجب على الخادم تحديث كل مخزن.
لتعديل ذلك، يجب تعديل القيمة التالية في ملف "paper.yml":
- container-update-tick-rate: 3 #الافتراضي: 1
لا يجب ضبط القيمة أعلى من 5، وإلا قد يصبح المخزن به بعض الأخطاء! في أوضاع اللعب مثل SurvivalGames، حيث يريد جميع اللاعبين الوصول إلى الصناديق في الوسط والحصول على أفضل العناصر، يجب ترك القيمة عند "1".
تحديثات الإضاءة (Light-Updates)
هنا أيضًا يقدم Paper Spigot خيارًا بديلًا لتحسين تحديثات الإضاءة في العالم. مع هذه الطريقة، لا تتم تحديثات الإضاءة داخل الـ tick، مما قد يسبب توقف الخادم أحيانًا حسب حجم التحديث، بل تتم خارج الـ tick. يُسمى هذا بـ async threads في ماينكرافت.
لتعديل ذلك، يجب تعديل القيمة التالية في ملف "paper.yml":
- queue-light-updates: true #الافتراضي: false
حفظ بيانات الـ Chunk
بمجرد إجراء تغييرات في chunk، لا تُكتب التغييرات مباشرة على القرص الصلب، بل تُحمّل أولًا في الذاكرة RAM. مع ذلك، تُحفظ كل التغييرات بشكل متكرر، مما قد يسبب تقطيعًا شديدًا، خاصة عند رغبة الخادم في حفظ تغييرات ضخمة.
مع هذا التغيير، نقلل الحد الأقصى لعدد الـ chunks التي يمكن حفظها في عملية حفظ واحدة. بتغيير هذا الخيار، تُستخدم الذاكرة RAM أكثر لأن التغييرات تبقى في الذاكرة لفترة أطول!
يجب تعديل الإعداد التالي في ملف "paper.yml":
- max-auto-save-chunks-per-tick: 10 #الافتراضي: 24
الريدستون (Redstone)
يُستخدم الريدستون كثيرًا مع دوائر قد تكون ضخمة جدًا. في الخوادم العامة، هذا أحيانًا يكون نقطة ضعف في حوالي 90% من الخوادم، حيث يمكن أن يسبب تقطيعًا كبيرًا. هنا نستخدم معالجة بديلة للريدستون من Paper Spigot، تجعل الريدستون شبه غير ضار مع الحفاظ على نفس الوظائف كما في Vanilla!
لتعديل ذلك، يجب تعديل الإعداد التالي في "paper.yml":
- use-faster-eigencraft-redstone: true #الافتراضي: false
تحذير! في بعض الحالات قد يغير هذا طريقة عمل الريدستون بشكل كبير!