Openapoc: सिटीस्केप में बहुत सारी नष्ट हो चुकी टाइलें अल्ट्रा-स्पीड में खेल को धीमा करने के लिए प्रतीत होती हैं

एक मिशन पर निर्माण वाहन जैसे शत्रुतापूर्ण वाहन भी प्रभाव डालते हैं

बाद में सेव गेम में एक और उदाहरण
save_SuperHuman 1.zip

वाहन भी फंसते नजर आ रहे हैं

फंसे हुए वाहन का पता लगाएं
यह मेगा-फ्लायर के ऊपर है, संलग्न सहेजें
save_SuperHuman 1.zip

मैं फंसे हुए वाहन (निर्माण वाहन 31) को डिबग कर रहा हूं।
सेवगेम के समय इसके मिशन हैं:

W 7613175674 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): CLICKED VEHICLE Construction Vehicle 31 at {42.7708,63.5,7.5}
W 7613244067 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission GotoLocation {43,63,2}
W 7613263414 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission RecoverVehicle 
W 7613286861 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission GotoBuilding BUILDING_WAREHOUSE_THREE

हालाँकि गंतव्य (43,63,2) को (43,63,7) पर फिर से लिखा जाता है।
उस बिंदु के बाद, वाहन (४३, ६३, ७) पर जाने की कोशिश के बीच दोलन करता है और प्रत्येक कॉल के साथ एक यादृच्छिक पास के लक्ष्य को सेट करने के लिए:

After setPathTo: Vehicle [Construction Vehicle 31] path: (41,63,7) -> (41,63,7) -> (42,63,7) -> (43,63,7)
After setPathTo: Vehicle [Construction Vehicle 31] path: (43,63,7) -> (43,63,7) -> (42,64,6) -> (41,63,5) -> (41,62,4)
After setPathTo: Vehicle [Construction Vehicle 31] path: (41,62,4) -> (41,62,4) -> (41,62,5) -> (41,62,6) -> (42,63,7) -> (43,63,7)
After setPathTo: Vehicle [Construction Vehicle 31] path: (43,63,7) -> (43,63,7) -> (43,62,7) -> (42,61,6)
After setPathTo: Vehicle [Construction Vehicle 31] path: (42,61,6) -> (42,61,6) -> (43,62,7) -> (43,63,7)
After setPathTo: Vehicle [Construction Vehicle 31] path: (43,63,7) -> (43,63,7) -> (44,64,6) -> (45,65,5) -> (45,65,4)
...

इसे देखने के लिए धन्यवाद @ashenomo <3

यदि आप कोई समाधान ढूंढ सकते हैं तो मैं बहुत आभारी रहूंगा

आदर्श रूप से, हम चाहते हैं कि वाहन यह पहचान ले कि यह एक लूप में फंस गया है और एक उपयुक्त, स्पष्ट, अंतिम गंतव्य के लिए एक नया मिशन उत्पन्न करता है क्योंकि मुझे संदेह है कि यह यादृच्छिक लक्ष्य पर एक चेक की कमी है जो एक उपयुक्त गंतव्य है जो लूप को मजबूर करता है

मैंने देखा कि जब वाहन इन लूपों में फंस जाते हैं तो वे अक्सर लैंडिंग ट्यूब टाइलों, या मेगा-फ़्लायर्स फ़ैक्टरियों में होते हैं।

निश्चित नहीं है कि मेगा-फ्लायर फैक्ट्री विशेष रूप से इस तरह के मुद्दे का कारण क्यों बनती है, जब तक कि कहीं खराब टाइल प्रकार न हो ???

ऐसा लगता है कि यह "साइड-स्टेपिंग" लॉजिक है, जो तब ट्रिगर करने के लिए होता है जब गंतव्य पर किसी अन्य वाहन का कब्जा होता है। लक्ष्य को अस्थायी रूप से पास की खाली टाइल में बदल दिया गया है। एक बार जब वाहन उस टाइल पर पहुंच जाता है, तो वह फिर से मूल लक्ष्य पर जाने की कोशिश करता है।

हालाँकि इस मामले में, किसी तरह साइड-स्टेपिंग का कारण बनने वाला वाहन CV31 है, यानी यह सोचता है कि यह खुद से टकराने वाला है। कोड
अतिरिक्त लॉग मैंने इसे दिखाते हुए जोड़ा:

W 14531114914 void OpenApoc::VehicleMission::setPathTo(OpenApoc::GameState &, OpenApoc::Vehicle &, Vec3<int>, int, bool, bool):  ** setPathTo for [Construction Vehicle 31] to (43,63,2), maxIter:450, cV:Y, giveUp:N, currentPath n:0
W 14531141711 void OpenApoc::VehicleMission::setPathTo(OpenApoc::GameState &, OpenApoc::Vehicle &, Vec3<int>, int, bool, bool):  *** adjustTargetToClosestFlying: [Construction Vehicle 31] (43, 63, 2), piNe: N
W 14531234219 static bool OpenApoc::VehicleMission::adjustTargetToClosestFlying(OpenApoc::GameState &, OpenApoc::Vehicle &, Vec3<int> &, bool, bool, bool &): Target (43,63,7) contains vehicle [Construction Vehicle 31]. This will trigger a target adjustment.

यह सुनिश्चित करने के लिए एक अतिरिक्त चेक जोड़ना कि वाहन खुद से बचने की कोशिश न करें एक अच्छा विचार लगता है।
उस ने कहा, मुझे यकीन नहीं है कि साइड-स्टेपिंग इसका समाधान क्यों नहीं करता है ..

कुछ और डिबग नोट:

• वाहन के मिशन हैं:

W 417133364405 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission GotoLocation {43,63,2}
W 417133397242 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission RecoverVehicle 
W 417133421554 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission GotoBuilding BUILDING_WAREHOUSE_THREE

• 43,63,2 पहुंच योग्य नहीं है - इस पर MEGAFLYER_TWO भवन का कब्जा है।
• यात्री ऊपर जाकर निकटतम पहुंच योग्य टाइल की तलाश करते हैं। इस मामले में यह 43,63,7 है।
  
• pickNearest इस गोटोलोकेशन मिशन के लिए गलत है - इसलिए इसे तब तक पूरा नहीं किया जाएगा जब तक कि वाहन सटीक स्थान पर नहीं पहुंच जाता। जो असंभव है।
• यह देखते हुए कि इसके बाद एक रिकवर वेहिकल मिशन है, शायद एक दुर्घटनाग्रस्त वाहन 43,63,2 पर समाप्त हो गया और इस परिवहन को इसे पुनर्प्राप्त करने के लिए सौंपा गया। मैं यह देखने के लिए पहले के सेवगेम का प्रयास करूँगा कि ये मिशन कैसे बनाए गए।
• पिछली टिप्पणी में मेरे द्वारा बताए गए चेक को जोड़ने से (बचने के लिए वाहनों की तलाश करते समय स्वयं को ध्यान में न रखें) वाहन को लूप में जाने से रोकता है, लेकिन अब इसके बजाय यह केवल 43,63,7 पर अटक जाता है।

इस पहले सेवगेम को देखते हुए:

मुझे लगता है कि यह नष्ट टाइलों से संबंधित है, क्योंकि ऐसा लगता है कि कुछ इमारतों को छापे से गिरा दिया जाता है

अल्ट्रा-स्पीड पर रखे जाने पर सिटीस्केप अविश्वसनीय रूप से धीमा प्रतीत होता है
नामुमकिन होने की हद तक

कृपया संलग्‍न सहेजें ढूंढें

SuperHuman_Slow.zip

ब्लेज़र टर्बो बाइक 49 (नष्ट हो चुके हेड्स ब्लॉक के पास) (86,78,2) तक पहुंचने की कोशिश कर रहा है, जो एक नष्ट सड़क टाइल है। लेकिन इसी तरह अटके हुए निर्माण वाहन के लिए, मैं देखता हूं कि इस वाहन के लिए हर टिक में सेटपाथ को बुलाया जा रहा है जो शायद मंदी में योगदान देता है।

फिक्स के लिए यहां एक पीआर है (केवल मैन्युअल रूप से सत्यापित):
https://github.com/OpenApoc/OpenApoc/pull/563