Frantic activity of AI-controlled relics

[Langbart]

to reproduce

• start a map with ai controlled players and some relics (currently at [27531] there is a bug, wait till ​Phab:D4934 has been merged)

  # 1v1 AI match with 14 relics; small map; pay attention to the relics being captured
  pyrogenesis -autostart-size=128 -autostart="random/mainland" -autostart-ai=1:petra -autostart-ai=2:petra -autostart-victory=capture_the_relic -autostart-reliccount=14 -autostart-player=-1
  

• move the game speed to 20x
• wait till some captured relics reach the civic center
• notice the frantic movement of the relic trying to find a spot

replay

• attachment:commands_27531_D4933_D4934.txt:ticket:6385​

reproducible

• issue is not reproducible on A23b
• a bit observable in A24b and A25b, but they find their position more quickly and are not trapped in an endless loop
• issue is reproducible in A26

bisect

(none)

[Freagarach]

Looks like unit pushing in combination with the AI tasking the relic. We might need to check what the AI wants the catafalque to do. (E.g. if it tasks to a very specific spot, don't do that.)

[Langbart]

The pusing changes may have made the problem even more obvious.

• [25182]
• [26245]
• [26261]

The problem is not present in A23b [21946] and is noticeable in A24b [24937], but not as extreme as currently in the dev version.

Below a GIF of A24b they show the same frantic behavior, but stop faster.

[Langbart]

Turning off the CC obstruction, it shows us the position to which the AI sends the relics.

binaries/data/mods/public/simulation/templates/structures/athen/civil_centre.xml

@@ -14 +14 @@
       units/{civ}/cavalry_javelineer_b
     </Entities>
   </Trainer>
+  <Obstruction>
+    <BlockMovement>false</BlockMovement>
+  </Obstruction>
   <VisualActor>
     <Actor>structures/athenians/civil_centre.xml</Actor>
   </VisualActor>

The AI orders them in the center of the CC, get the exact position.

binaries/data/mods/public/simulation/ai/petra/victoryManager.js

@@ -474 +474 @@
     if (bestBase.accessIndex == accessIndex)
     {
         let bestBasePos = bestBase.anchor.position();
+        warn(uneval(['bestBasePos', bestBasePos]))
         criticalEnt.move(bestBasePos[0], bestBasePos[1]);
     }
 };

---

possible solutions ?

(1) Passability Class

Reducing the PassabilityClass stops the effect also, but the units are overlapping too much.

binaries/data/mods/public/simulation/templates/template_unit_catafalque.xml

@@ -50 +50 @@
     <Formations disable=""/>
   </UnitAI>
   <UnitMotion>
-    <PassabilityClass>large</PassabilityClass>
+    <PassabilityClass>default</PassabilityClass>
     <WalkSpeed op="mul">0.55</WalkSpeed>
     <Acceleration op="mul">0.275</Acceleration>
     <Weight op="mul">10.0</Weight>

---

(2) obstructionRadius

binaries/data/mods/public/simulation/ai/petra/victoryManager.js

@@ -474 +474 @@
     if (bestBase.accessIndex == accessIndex)
     {
         let bestBasePos = bestBase.anchor.position();
-        criticalEnt.move(bestBasePos[0], bestBasePos[1]);
+        const {max} = gameState.getEntityById(bestBase.anchorId).obstructionRadius();
+        criticalEnt.moveToRange(bestBasePos[0], bestBasePos[1], 0, max);
     }
 };

[Langbart]

The actual bug might have been introduced by one of the unit motion changes from wraitii, all the above solutions rather "hide" the actual problem.

Pushing back 1 milestone.

git log A23...A24 --author wraitii -i --grep="unit.*motion" --oneline | wc -l
# a total of 58 commits from @wraitii containing UnitMotion in the commit message    
58

[wraitii]

The 'back and forth' behaviour looks a little buggy, not sure it's related to pushing or just unitmotion itself. It's a little odd that we only really see it happen to Catafalques to me, which aren't really anything special.

Investigating should determine why the unit (probs UnitAI) doesn't run into a 'stop' condition if this happens forever.

--

With that being said, I think it is a correct fix to do solution 2 above. The AI should order the unit to move in range of the entity, and not to a fixed position. This will let UnitAI make better decisions, and handles some other cases like mods that make moving CCs etc. This is independent of fixing a possible underlying issue in unit motion.

[Freagarach]

The flip-flop can be reproduced with rams (task them to the center of a large CC) as well. But sometimes it is kind of hard. ^^

[Freagarach]

In 27544:

Fix AI tasking catafalques to the center of the CC.

There is some unit-motion/unitAI bug that makes them not reach the center and hence idleness.

Refs. #6735 by fixing the specific PetraAI <> catafalque case.
Reported and solution by: @Langbart

[Freagarach]

(One may close this ticket due to the linked commit and make a new one, or keep this open for the rest of the issue.)

[Langbart]

#6741 was created to keep track of the problem, which is more generally described as this ticket was.