Fix dancing AI (#551)

[kymckay]

Some sort of conflict between disableAI "PATH" and setUnitPos "UP"
A bug in setUnitPos "UP" causes AI to dance when engaged (repeatedly trying to lower their profile but can't I assume)

[commy2]

Honestly, I liked doStop more. It didn't have permanent effects, so the AI could be given other waypoints / orders after they garrisoned a building.
No setUnitPos "UP" is a huge loss too. Prone AI tends to fire through the floor/ceiling and even walls.

[kymckay]

I was under the impression doStop did have permanent effects unless you executed specific script commands on the AI afterwards? (just like disableAI "PATH" but much more hacky).

Also, in my testing after removing this line, the AI actually only seemed to go prone if exposed at an outdoor building position or similar (which I kinda like - if we do add it back, would be nice to only apply it to units inside buildings).

[kymckay]

Decided to look into doStop for you, it actually causes the same dancing bug when used with setUnitPos 😢 However I'm with you now, it seems better because AI will move to react to combat.

On further analysis, I think this might actually just be a bug with setUnitPos "UP", I've got units moving around showing the same behaviour now.

[commy2]

Hmm. Only alternative is https://community.bistudio.com/wiki/setUnitPosWeak, but that will be overruled by the AI FSM, so there is not much point in using it.

[kymckay]

It could work because they'd be detached from their formation with doStop, however if it did work I have a feeling it would cause the same problem

[ShizCalev]

With this change, when issuing the ACE defend area command to units, once the patrolling units hit their cycle waypoint, all the units whom were in buildings abandon their posts and rejoin formation to take up patrol.

This issue was not experienced prior to this commit.

You can work around this by deleting the patrol's cycle waypoints, so it appears that doStop doesn't have permanent effect, and is just being overridden by the cycle.

[commy2]

I think that is the expected behavior though. If a waypoint is finished, the whole group should begin with the next waypoint.

[ShizCalev]

Previous behavior was that issuing Defend Area would have units garrison buildings in the area, with a 7% chance of a unit going onto a patrol around the area. Once the patrol group finished through all waypoints and hit the cycle, they would repeat the same patrol with the same select units, and the rest would stay garrisoned (since pathing was disabled on the ones in the buildings.)

Now the behavior is that units garrison buildings, 7% chance at patrolling, however once the patrol group reaches the final waypoint and hit the cycle, all units leave their buildings and start patrolling the area in a formation.

AI shouldn't be dropping out of buildings under defend area, as that would make the command redundant with Patrol Area.

[commy2]

That wasn't the case before @SilentSpike changed the taskDefend module / waypoint in the first place.
We cannot use disableAI "PATH" as it's broken.
I think placing waypoints after any of these taskX waypoints is undefined behavior.

[ShizCalev]

May I ask how disableAI "PATH" is broken? I know setUnitPos "UP" is, however this is the only I've heard about disableAI (and there are a couple other mods that I use that that information would be relevant for.)

I tired out replacing doStop _unit; with the current version with disableAI "PATH" and the AI seem to stay in the buildings as intended, and shoot freely as desired (and present no dancing issue, as was the reason for this PR)

[commy2]

Yeah, my bad. setUnitPos is broken. However, units being stuck after a taskDefend waypoint is not intentional either.