مستودع RPCS3 الرسمي، ومنه يتم إنشاء Builds جديدة بعد دمج التغييرات.
وش أفضل إصدار من RPCS3؟
للاستخدام اليومي
استخدم أحدث Master Build عشان تحصل على آخر إصلاحات الأداء والتوافق.
لوجود Regression
استخدم نسخة أقدم مؤقتًا إذا لعبة كانت تشتغل ثم تعطلت بعد تحديث.
لاختبار ميزة جديدة
جرب Build خاص بـ Pull Request قبل دمجه، مع توقع وجود أخطاء.
القاعدة العامة: أحدث Master هو الأفضل لمعظم المستخدمين. الرجوع إلى
نسخة قديمة حل تشخيصي مؤقت، مو توصية بالبقاء على إصدار قديم دائمًا.
طريقة تحديث RPCS3 إلى أحدث Master
2
نزل أحدث Build من صفحة التنزيل الرسمية.
3
فك ضغط جميع الملفات داخل مجلد RPCS3 الحالي.
4
وافق على استبدال الملفات القديمة عند ظهور رسالة
Replace أو
Overwrite.
5
شغل المحاكي وتأكد من رقم الإصدار الظاهر في شريط العنوان.
استبدال ملفات البرنامج ما يحذف إعداداتك أو الألعاب المثبتة أو ملفات
الحفظ الموجودة في مجلد بيانات RPCS3.
لا تنسخ ملفات النسخة الجديدة والمحاكي شغال، لأن بعض الملفات تكون
مستخدمة وقد يفشل استبدالها بشكل كامل.
طريقة تشغيل إصدار أقدم بدون تخريب النسخة الحالية
الطريقة التالية تخص نسخة Windows المحمولة، وتسمح لك تحتفظ بأكثر من
ملف تنفيذي داخل نفس المجلد مع استخدام نفس الألعاب والـFirmware والحفظ.
1
افتح Build History ونزل الإصدار القديم المطلوب.
2
فك الضغط وخذ ملف rpcs3.exe فقط.
3
غير اسمه إلى اسم واضح مثل
rpcs3.0.0.40-19000.exe.
4
حط الملف داخل مجلد تثبيت RPCS3 الحالي بجانب
rpcs3.exe.
5
شغل الملف المعاد تسميته وقت ما تحتاج تختبر الإصدار القديم.
إذا ظهرت رسالة مرتبطة بـQt، انسخ محتويات
qt\plugins\ من أرشيف الإصدار القديم
إلى مجلد RPCS3 الرئيسي حسب التعليمات الموجودة في صفحة RPCS3 الأصلية.
لا تستبدل ملف rpcs3.exe الأساسي بالإصدار
القديم. إعادة تسمية النسخة القديمة تخليك ترجع لأحدث إصدار بسهولة.
تحميل Build من Pull Request قبل دمجه
Builds الخاصة بالـPull Requests تستخدم للاختبار فقط. مكان الأزرار
قد يتغير حسب واجهة GitHub ونظام CI المستخدم، لكن المسار العام واحد:
افتح الفحوصات الناجحة ثم حمل Artifact الخاص بنظامك.
1
افتح صفحة Pull Request المطلوبة داخل مستودع RPCS3.
2
افتح تبويب Checks أو قسم
فحوصات الدمج أسفل صفحة النقاش.
3
اختر الفحص الخاص بنظامك، مثل Windows أو Linux.
4
افتح تفاصيل الفحص أو رابط نظام CI بعد ظهور علامة النجاح.
5
من قسم Artifacts نزل ملف Build.
تبويب Checks يعرض الفحوصات ونتيجة بناء التغييرات داخل Pull Request.
مثال رسمي من GitHub على مكان ملف Artifact بعد نجاح Workflow.
نجاح Build ما يعني أن التغيير مستقر أو بيتم دمجه. لا تستخدم PR Build
كنسخة رئيسية، ولا تبلغ عن مشاكلها كأنها موجودة في أحدث Master.
وين تلقى الإصدارات القديمة؟
صفحة Builds History الرسمية تسجل Master Builds المرتبطة بالـPull Requests،
وتعرض رقم الإصدار والتاريخ والمنصة وروابط التنزيل المتوفرة.
| المنصة |
أقدم Build مذكور في الدليل الأصلي كنسخة قابلة للتنزيل |
التاريخ |
| Windows |
0.0.5-6906 |
2018-06-08 |
| Linux |
0.0.5-7644 |
2018-12-31 |
ظهور Build داخل السجل ما يضمن أن ملفه ما زال متوفرًا لكل منصة.
بعض السجلات القديمة محفوظة كمعلومات فقط بدون رابط تنزيل.
كيف تحدد الإصدار اللي سبب Regression؟
بدل اختبار عشرات الإصدارات واحد واحد، استخدم طريقة البحث النصفي:
كل اختبار يقسم المسافة بين النسخة السليمة والمعطوبة إلى نصفين.
Good
آخر Build تشتغل فيه اللعبة بشكل صحيح
→
Middle
Build يقع تقريبًا في المنتصف
→
Bad
Build تظهر فيه المشكلة
1
حدد Build حديث تظهر فيه المشكلة وسجله كـ
Bad.
2
حدد Build أقدم ما تظهر فيه المشكلة وسجله كـ
Good.
3
اختبر Build موجود بالنصف بين Good وBad.
4
لو المشكلة موجودة، سجل النسخة الجديدة Bad. لو مو موجودة، سجلها Good.
5
كرر الاختبار بالنصف الجديد إلى أن توصل لأول Build ظهرت فيه المشكلة.
سجل رقم كل Build ونتيجته واحتفظ بنفس إعدادات اللعبة وملف الحفظ ومكان
الاختبار، عشان تكون المقارنة عادلة.
وش ترفق عند الإبلاغ عن Regression؟
1
اسم اللعبة والـSerial وإصدار تحديث اللعبة.
2
آخر Build سليم ورابطه أو رقمه.
3
أول Build معطوب ورابطه أو رقمه.
4
خطوات واضحة لإعادة المشكلة.
5
ملف RPCS3.log وصورة أو فيديو يوضح الفرق.
0 تعليقات