तीसरे बैच की योजना: हाइलाइट सिस्टम + ब्लूप्रिंट सिस्टम

cmclient की दो उच्च-मूल्य वाली सुविधाओं का गहन अध्ययन किया गया, यह पृष्ठ पोर्टिंग योजना और कार्यभार मूल्यांकन दर्ज करता है।

एक, ऑब्जेक्ट-स्तरीय हाइलाइट सिस्टम (cm_highlight, 2888 पंक्तियाँ)

कार्यक्षमता: निर्माण उपकरण सक्रिय होने पर, निर्मित होने वाली वस्तु का वास्तविक समय हाइलाइट — रेल पूर्ण खंड, स्टेशन पूरा क्षेत्र, सड़क/पार्किंग, सिग्नल, पुल, सुरंग, घाट, एयरपोर्ट, उद्योग आदि 15 प्रकार की वस्तुओं का सटीक पूर्वावलोकन।

पोर्टिंग निर्भरताएँ (vanilla API → jrpm API):

cmclient निर्भरता	jrpm समकक्ष
DrawSelectionSprite / SetSelectionTilesDirty / DrawTileSelectionRect / DrawAutorailSelection (viewport.cpp आंतरिक)	मौजूद है लेकिन हस्ताक्षर भिन्न (jgrpp ने पुनर्गठित किया), एक-एक करके संरेखित करने की आवश्यकता
TileZoning (टाउन ज़ोनिंग रंग)	jrpm में नहीं → नया बनाना होगा
_fn_mod जैसी वैश्विक स्थिति	cmclient-विशिष्ट → पुनः डिज़ाइन करने की आवश्यकता
ObjectTileHighlight::make_rail/road_stop/... प्रत्येक ऑब्जेक्ट कंस्ट्रक्टर	NewGRF स्टेशन/सड़क API पर निर्भर, jrpm और vanilla में अंतर है

कार्यभार: लगभग 2–3 राउंड (प्रति राउंड 4–6 घंटे), मुख्य कठिनाई व्यूपोर्ट ड्रॉइंग पाइपलाइन के संरेखण में।

दो, ब्लूप्रिंट सिस्टम (cm_blueprint, 660 पंक्तियाँ)

कार्यक्षमता: क्षेत्र चुनें → निर्माण कमांड अनुक्रम रिकॉर्ड करें (रेल/स्टेशन/सुरंग/पुल/सिग्नल) → 16 स्लॉट भंडारण → एक क्लिक रीप्ले निर्माण + घुमाव।

पोर्टिंग निर्भरताएँ:

cmclient निर्भरता	jrpm समकक्ष
cm_commands.hpp कमांड ऑब्जेक्ट लेयर (as_company / with_callback / set_auto / no_estimate + 100+ जनरेटेड कमांड क्लासेज़, 2251 पंक्तियाँ)	jrpm में यह अमूर्तता नहीं है → पहले पोर्ट/पुनर्लेखन आवश्यक
cm_station_gui.hpp का _station_gui स्थिति	jrpm स्टेशन GUI स्थिति संरचना भिन्न
sp<Blueprint> स्मार्ट पॉइंटर	jrpm std::shared_ptr का उपयोग कर सकता है
BlueprintCopyArea का टाइल ट्रैवर्सल	TileIndexDiffC जैसे सामान्य API पर निर्भर (jrpm में है)

कार्यभार: लगभग 2–3 राउंड (कमांड ऑब्जेक्ट लेयर सहित)।

तीन, अनुशंसित कार्यान्वयन क्रम

चरण 1: कमांड ऑब्जेक्ट लेयर (cm_command_type डिज़ाइन, jrpm के Command<T>::Do/Post के साथ पुनः कार्यान्वित)
         —— ब्लूप्रिंट और कमांड रीप्ले (load_commands) का साझा आधार
चरण 2: ऑब्जेक्ट-स्तरीय हाइलाइट (व्यूपोर्ट पाइपलाइन संरेखण, एक-एक ऑब्जेक्ट पोर्ट)
चरण 3: ब्लूप्रिंट (कॉपी/रोटेट/स्लॉट/रीप्ले)
चरण 4 (वैकल्पिक): कमांड रीप्ले (lzma पूर्ण-गेम रीप्ले) + टाउन ज़ोनिंग (growth_tiles, सेव विस्तार की आवश्यकता)

पूर्व शर्त स्पष्टीकरण

ये तीन सुविधाएँ कुल मिलाकर लगभग 5000+ पंक्तियाँ हैं, कमांड सिस्टम/सेव/व्यूपोर्ट तीन मुख्य परतों में फैली हुई हैं, और jrpm में न होने वाली मध्यवर्ती परतों (कमांड ऑब्जेक्ट, ईवेंट बस, बिटस्ट्रीम सीरियलाइज़ेशन) पर निर्भर करती हैं। एक स्वतंत्र विशेष परियोजना के रूप में आगे बढ़ना अधिक सुरक्षित है — बैचों में निष्पादित करने, प्रत्येक बैच को संकलित + मल्टीप्लेयर सत्यापित करने के बाद कमिट करने की सिफारिश की जाती है, एक बार में बड़े बदलाव से बचने के लिए जिससे प्रतिगमन का पता लगाना मुश्किल हो।