تسجيل الأوامر وإعادة التشغيل (Command Record / Replay)

نقل إعادة تشغيل أوامر cmclient (الدفعة الخامسة، commit f113acce28). لا يتم نقل طبقة كائن أوامر cmclient——بدلاً من ذلك، يتم استخدام البنية التحتية لتسلسل الأوامر المدمجة في jrpm مباشرة (DynBaseCommandContainer)، متجاوزاً "طبقة كائن الأوامر" بالكامل.

أوامر الكونسول

cmdrecord [start [file]]    # بدء التسجيل (الملف الافتراضي cmdrecord.jrcm، يُحفظ في الدليل الشخصي)
cmdrecord stop              # إيقاف (تأخير 10 tick لانتظار تفريغ قائمة انتظار الأوامر ثم الكتابة)
cmdreplay <file>            # إعادة التشغيل: إلغاء التسلسل وتنفيذ كل أمر فوراً

نقاط التنفيذ

• خطاف التسجيل: CommandRecordLog يُعلق بعد تنفيذ الأمر في DoCommandPInternal——هذه هي نقطة التنفيذ الحقيقية الوحيدة للأوامر المحلية والشبكية وإعادة التشغيل، لن يتم تسجيلها بشكل مكرر.
• التسلسل: cmd / tile / error_msg / payload / company يتم تسلسلها بدون فقدان باستخدام DynBaseCommandContainer::Serialise؛ تنسيق الملف JRCM magic + version + count + إدخالات.
• الإيقاف المتأخر: cmdrecord stop يضع علامة تأخير 10 tick، StateGameLoop يتحقق كل إطار (CommandRecordTick) لضمان التقاط الأوامر التي تم وضعها في قائمة الانتظار قبل المسح.
• تنفيذ إعادة التشغيل: يتم تنفيذ كل أمر فوراً كمسار أمر خادم (DCIF_NETWORK_COMMAND)، حتى لو لم يتم تحديث رأس count لملف إعادة التشغيل، يمكن قراءة البيانات الفعلية.

التحقق

خادم مخصص E2E: تسجيل pause ← ملف تسجيل 26 بايت ← إعادة تشغيل في خريطة جديدة ← Game paused (manual) + Replay finished: 1 executed, 0 failed.

الاستخدام النموذجي

cmdrecord start build1     # بدء التسجيل
# ... في اللعبة، مد السكك الحديدية، بناء المحطات ...
cmdrecord stop             # إيقاف والكتابة
# بعد تغيير الخريطة أو استرداد الانهيار:
cmdreplay build1           # إعادة بناء جميع العمليات بنقرة واحدة