Please let setUnitpos override any AI stance handling, as it used to.

Indeed AI units get stuck and unresponsive. It may be related to some animation bug, or pathfinding or something else. We definetely need some solution here.

@giova:

1. CPU cycling is not a key factor. It's possible to get AI units unresponsive even with a few AI units and high FPS;

2. I've never seen a single case in which a single AI unit opened fire without being seen, care to repro? Also units are not supposed to open fire when *engaged*, but rather when *detected*.

Finally, you may get units to rush to some position while in danger mode, but that requires some scripting which ends up making them more vulnerable.

Same here, stuck at the "assemble" point.
Cinema borders on, player can look around, but no movement nor interation are possible.

DEV 1.11.115723

I think Killzone_Kid gave valid and useful hints here.

To me selectweapon "Throw" was working fine within ArmA3 1.08 and not later, so i think that whatever is broken, it was broken within DEV builds just after 1.08.

Moved a note to other ticket:
http://feedback.arma3.com/view.php?id=14177

@DarkDruid:
Any chance we'll got this fixed soon?

@Killzone_Kid:

can't reproduce what you write.
Just tested on 10/01/2014 DEV version.
The following code, put into unit init field:

handle = this spawn {
sleep 1;
_this selectWeapon "Binocular";
hintc format["%1", currentweapon _this];
};

shows current weapon being the original weapon and not binocular even immediately after selectweapon execution.
So i think selectweapon is broken.
It worked fine till version 1.08 though.

---

Run the attached repro (selectweapon_bug_2.Stratis.zip).

@Killzone_Kid:

Bah. You're right.
I originally tested the code with "Throw", then swapped to "Binocular" to keep on track with original report.
Forgot checking unit inventory.

Code:

handle = this spawn {
sleep 1;
_this selectWeapon "Throw";
hintc format["%1", currentweapon _this];
};

is not working right anyway.
I've seen this ticket of yours, looks related:
http://feedback.arma3.com/view.php?id=14177

And poles, gates

Having observed AI behaviour having currentCommand = "ATTACK", i'd say some scripting commands are briefly able to override the command, but looks like "ATTACK" takes over again, almost immediately.

I also tried to override currentCommand via a custom doFSM call, but the call appeared to be:

a) skipped most of times;
b) rarely executed with substantial delay, then quickly overriden.

ArmA 3, v1.10 official:
the following code, put into a unit (named buddy) init field:

oneachframe { buddy selectWeapon "Throw"; buddy globalchat format["%1", currentweapon buddy]; };

Always returns unit's primary weapon.
Enclosing code into a spawn {} block does not change the result.

Looks fixed now.

Indeed AI units get stuck and unresponsive. It may be related to some animation bug, or pathfinding or something else. We definetely need some solution here.

@giova:

1. CPU cycling is not a key factor. It's possible to get AI units unresponsive even with a few AI units and high FPS;

2. I've never seen a single case in which a single AI unit opened fire without being seen, care to repro? Also units are not supposed to open fire when *engaged*, but rather when *detected*.

Finally, you may get units to rush to some position while in danger mode, but that requires some scripting which ends up making them more vulnerable.