Possible bug in messenger_escort MAI

[vghetto]

Hi,

Say you have messenger_escort defined for a side with [filter] as the main unit that is supposed to reach the final waypoint, and [filter_second] as the protection for that main unit.
The MAI gets stuck doing nothing if one of the [filter_second] units either blocks the path of the main unit or is standing on the final waypoint that the main unit is supposed to reach.

I might be mistaken on whether that is actually what's happening. I haven't delved into the lua code to make sure, but by observation, what I described might be it.

[octalot]

Is this 1.14, 1.15 or both?

[vghetto]

I noticed it while playing on 1.15.15.
I'll try 1.14 and let you know if it happens there. I haven't experienced it on 1.14 so far.

[mattsc]

I cannot reproduce this, unless I am misunderstanding what you mean. I tested things in the messenger escort test scenario and things proceed just fine even if you put escort units on the last waypoint. It is conceivable that there is a situation when all the escort units think that they are already in the best position and somehow that blocks progress for the messenger, but I have not been able to create this. So I'd need a bit more information (ideally a saved game) to be able to figure out what is going on.

[vghetto]

hmm, I wasn't able to reproduce it on 1.14 but it does happen on 1.15.16

I'm attaching the demo code in which this happens
right click on the map and select spawn orcs
press end turn for the orcs to spawn.
press end turn again and the orc leader is supposed to go to a nearby location and build a keep.

If they do build a keep then right click to kill and remove the keep and try again with a new spawn.
They won't always get stuck but sometime they will.

In 1.14 the secondary orc moved aside and allowed the leader to move in and build the keep.
In 1.15 the secondary didn't move out of the way and the leader was stuck in place.

Sorry for the messy code, I had to rip it out from WF and use duct tape to make it run as stand alone demo without WF as a dependency. Ignore the code & the comments, they were copy-pasted and meaningless out of context.

[mattsc]

Thanks! I can see what you are talking about now. In my case, the secondary orc does move out of the way, but the orc leader does not move to the waypoint this turn (he does, however, on the next turn). I will have to look into what exactly causes this and what to do about it.

Thanks much for putting together the test code and don't worry about the duct tape. It is, after all, the handyman's secret weapon. I use it all the time myself.

[vghetto]

Thank you. I'm attaching a 1.15.16 save file in which what I'm saying takes place. Load with show replay checked to see
In this save file the leader doesn't move at all. One of the trolls does however move up and down.

[mattsc]

This is indeed a bug in the messenger AI. When considering the "next hop" for the messenger, it is not taking into account that own units might be blocking the way. Most of the time that does not matter, but you found a use case where it does.

I'll fix that for 1.15.17. If you want to test it in the meantime, you can change this line in the Micro AI code to:

local next_hop = AH.next_hop(messenger, x, y, { path = path, avoid_map = avoid_map, ignore_own_units = true } )

There is probably at least one other place where this also needs to be done, but for your test case that should do the trick.

Thanks for reporting this!

[vghetto]

Thank you for the fix.
I just tried the change on version 1.15.16. That seems to fix it
I had a quick glace at the 1.14 version of messenger_escort. It already passed ignore_own_units to AH.next_hop. Was that the reason why I wasn't able to reproduce the bug on 1.14?

[mattsc]

Glad it is working with this. I still haven't had a chance to check out what else needs to be changed, but I'll make sure it's in 1.15.17; there are still a couple weeks left until that release.

I had a quick glace at the 1.14 version of messenger_escort. It already passed ignore_own_units to AH.next_hop. Was that the reason why I wasn't able to reproduce the bug on 1.14?

Yeah, that seems to be it. Which raises the question why I removed it. Looking at the commit that did so, it looks like I simply forgot to keep that parameter when I added [avoid] tag functionality. So it is very clearly a bug, thanks again for reporting it.