يُمنع استخدام التعديلات على جانب العميل (الكلاينت).

لا يوجد تعديل على جانب العميل (الكلاينت).

لن ندعم تعديلات العميل (الكلاينت) بأي شكل من الأشكال - سليكي

لماذا؟

1. لا حاجة لتحميلهم من مصدر خارجي.

   • تريد هايتيل تجنّب نظام بيئي مجزأ حيث يتطلب كل خادم (سيرفر) نسخة عميل (كلاينت) معدلة مختلفة.

2. أمان العميل (الكلاينت).

   • تشغيل ملفات .jar من مواقع الطرف الثالث على العميل (الكلاينت) يمكن أن يؤدي بسهولة إلى إدخال برمجيات خبيثة.

   لا نريد أن نعرّض اللاعبين لمخاطر الأمان والسلامة الموجودة في بعض منصات التعديلات (المودات) الأخرى.

3. استقرار العميل (الكلاينت).

   • قد تنتقل هايتيل إلى منصات أخرى حيث يكون تعديل العميل (الكلاينت) مستحيلاً، لذلك يقومون بتقييد الوصول إليه مبكرًا لتحديد الاتجاه الصحيح من البداية.

   نعتقد أن النتائج التي يحققها اللاعبون في ألعاب البناء الأخرى باستخدام تعديلات (مودات) العميل (الكلاينت) يمكن تحقيقها بسهولة باستخدام التعديلات (المودات) التي تعمل على جانب الخادم (السيرفر) لدينا. في ألعاب البناء الأخرى، يجب تثبيت تعديل (مود) على العميل (الكلاينت) للحصول على كتل (بلوكات) جديدة، وشخصيات غير قابلة للعب (شخصيات الكمبيوتر)، وواجهة المستخدم، وما إلى ذلك. أما هايتيل، فتقوم بكل ذلك بمجرد الاستماع إلى الخادم (السيرفر). سيقوم الخادم (السيرفر) بشكل أساسي بتعديل العميل (الكلاينت) مؤقتًا بطريقة آمنة جدًا لإضافة وتغيير تجربة اللعب الخاصة بك. يمكنك إنشاء نسختك الخاصة من (العالم) أوربيس، دون الاعتماد على أي من نماذجنا، أو موسيقانا، أو أساليبنا في توليد العالم، أو نظام القتال لدينا، أو أي عناصر أخرى. لديك السيطرة الكاملة، ويمكنك استخراج كل شيء دون الحاجة للمساس بالعميل (الكلاينت) أبدًا. فكر في طريقة عمل لعبة روبلوكس… أنت لا تغيّر تطبيقك أبدًا. كل ما عليك هو اختيار التجربة التي تريدها، وستحصل على كل ما تحتاجه دون تعديل عميلك (الكلاينت بتاعك) نفسه. - سليكي

الاستخدامات النموذجية لتعديلات (مودات) العميل (الكلاينت) هي:

• التغييرات التجميلية (حزم الموارد، المؤثرات البصرية، الأَرْدِيَة(الكيبات)، إلخ): المرئيات يتحكم بها الخادم (السيرفر)، وليس العميل (الكلاينت).
• الأداء: ستوفر اللعبة الأساسية عناصر التحكم اللازمة في الأداء.
• إمكانية الوصول: ستكون اللعبة الأساسية قابلة للوصول بشكل مستقل.
• واجهة المستخدم: تتحكم الخوادم (السيرفرات) في واجهة المستخدم، وليس العميل (الكلاينت).

التنبؤ من جانب العميل (الكلاينت)

تستخدم هايتيل التنبؤ من جانب العميل (الكلاينت) المعتمد على البيانات لتقليل التأخير(اللاج)، حيث تتم جميع التفاعلات على الخادم (السيرفر) ويتم إرسالها مرة أخرى إلى العميل (الكلاينت). هذا متاح بالفعل في بعض الأنظمة، لكنه محدود حاليًا، مع خطط لتوسيعه ودمجه بشكل أوسع في المستقبل. من المخطط أيضًا أن يعمل مع نظام البرمجة المرئية في المستقبل لتحقيق مزيد من التحسينات.

التنفيذ من جانب العميل (الكلاينت)

يستكشف الفريق إمكانية السماح بتنفيذ الأكواد من قبل العميل (الكلاينت) وهو مختلف عن تعديل العميل (الكلاينت)؛ فهذه الأكواد يُرسلها الخادم(السيرفر)، مع العلم أن ذلك ليس مضمونًا.

النماذج

يتعرف العميل (الكلاينت) وخط إنتاج الأصول على صيغة .blockymodel، وهي صيغة مخصصة لهايتيل. ستسمح لك الإضافة الرسمية لبرنامج Blockbench بتصدير النماذج إلى هذه الصيغة.

التفاصيل التقنية للعميل (للكلاينت)

سيكون هناك دائمًا نسخة واحدة فقط من العميل (الكلاينت) مدعومة حاليًا.

سيتم الحفاظ على تحديث نسخة جافا من قبلنا، ونحن حاليًا على أحدث إصدار (جافا ٢٥). لن تكون نسخة اللعبة قابلة للاختيار لتجنب فوضى الإصدارات التي واجهناها في شبكة خوادم (سيرفرات) هايبكسل. نحن نرغب ببساطة في التأكد من أن شبكات اللعب الجماعي يمكنها الاعتماد على أن اللاعبين يمتلكون أحدث نسخة من اللعبة، لتجنب الحاجة لدعم أكثر من 15 نسخة مختلفة من العميل (الكلاينت). - سليكي

العميل (الكلاينت) سيكون متعدد العمليات (multithreaded)

واجهة المستخدم الرسومية (GUI)

تم بناء واجهة المستخدم الرسومية باستخدام ربط C# عبر Noesis.

نظام البناء

تستخدم هايتيل NativeAOT (التجميع المسبق) لبناء العميل (الكلاينت)، حيث يتم تحويل كود #C إلى لغة الآلة للتوزيع. هذا يعني أنه، دون الحاجة لعكس لغة الآلة، يجب أن تمر التعديلات (المودات) عبر واجهة برمجة تطبيقات الخادم (API).

معلومات أخرى

يمتلك العميل (الكلاينت) نظام إصدار خاص به وبروتوكول للتفاعل مع الخوادم (السيرفرات).