Smokeskin

The attack strategy creates and controls the attack plans and the defend strategy creates the defend plans and the defend choke point plan.

The problem of switching choke points is correct. The harassing code had a similar problem with constantly switching target positions. That's why I changed it. I think the attack and defend plans have specific control mechanisms to avoid the fast switching, but I agree, the defend strategy should have a switching delay for the defend choke point plans. That could solve at least 'some' problems. But just like you said, the problem of the movement code to get 10 new problems for every solved problem makes changes in this area a real nightmare, especially the tactics. However, the switching delay for the choke points should be easy to do without the risk of unpleasant surprises.

A delay won't solve it. Moving back and forth between points at 10 sec intervals would be just as bad.

As I can see it, you don't have code in there that checks for the local situation, is my army able to beat the enemy where it is now? If yes, do an attack there. If not, you can either move to attack an undefended LP of the enemy, or move back to take up a defensive (waiting) position (preferably at an LP2), and that position should be mostly enemy free.

I could do this by just messing with your code, so Defendchokepointplan would also launch attacks and such. But to keep things right, I would much rather like to know, how (or where) is it decided what plan gets carried out? If I wanted to put in some checks to decide what plan to go for, where in the code should I be looking?

I don't really know how AttackState differs from HoldState and I haven't tested that exactly. I think you'd still get problems from the indecision in the code, where it switches what point to defend repeatedly. AttackState would also have to distinguish between situations where the troops are locally in trouble and should move to the designated point because there are real problems there (something unnatural for an attackstate, they'd just not attack), situations where the problems at the destionation are so grim they should just drop it altogether, and situations where they have local superiority and should do attack moves. In the end, I think these decisions can't be made at unit level.

I'm thinking along the same lines though, but at the Strategy/Plan level. If someone could tell me where the code that selects what Plan gets carried out and what units are assigned to it, then that would be the right way to fix it. If your units are mixed in with or near enemy units, you don't use Defend and DefendChokepoint on points near the enemy unless you really mean it. Either you do it to attack and repel or kill the enemy because you can, or you go to attack one of his undefended points or just move to Hold some uncontested area. Get rid of the indecisions and only do Hold if you can actually hold it. I don't think the HoldState code is wrong, it is just being used at inappropriate times where you shouldn't try to hold the position.

So far I haven't been able to figure out where the code selects what Plan to carry out though, it would be great if someone could point me in the right direction

I have identified some of the reasons why units are moving around back and forth instead of standing and fighting.

One problem is DefendChokePoint. It will repeatedly switch chokepoints with very short intervals, which sends units running back and forth, even while under fire. That is a problem in itself, that it gets stuck at "indecision points" like that - I think the algorithms even has a tendency to have these points act like attractors.

In the tactic files, BeginHoldState will do a move (not attackmove) if further than 60 away from the destination. This very often leads to units moving to hold a position, and actually being in range of the enemy units they're supposed to be fighting, but just running past them while getting gunned down, instead of just fighting them immediatedly. A check to see if enemies in range are in range of the destination, and if they are then do an attack move instead, might be the solution.
This issue becomes even worse when you take into account that the logic deciding on chokepoints to defend and such continously flips back and forth, so the units always finds themselves moving back and forth between points they'll never get close to.

I've been trying to do a few fixes for it, but they all seem to cause other problems, mainly that units get suicidal. My guess is that either I haven't really understood how the strategies and plans work together, or the unintentional effects of the code that handles defend plans/strategies and hold states that makes units move instead of fight and loses fights for no reason, has also masked that the retreat code isn't working properly, so fixing defend and hold code will require a fix to retreat code too.

I can't stress enough how big a problem this is. In almost every fight I see AI units running around like headless chickens, reducing their efficiency drastically, and they are in BeginHoldState when they're doing it, often switcing their destinations every few seconds. Most AI vs AI fights seem to be decided by what side first gets hit by this code while the other doesn't.

Unfortunately, while having tracked down the problem, I'm not yet fluent enough in the code to fix it properly.

I think the problems with random running around under long range fire is a similar but different issue, I haven't tested that one yet.

Nah. The end is fine and closing

local squad_filter = function( squad_ai )

Yeah, I just found out, notepad++ just doesn't recognize that, so it says it is unclosed.

No true