Erratic AI behavior, some groups follow waypoints, others remain static.

[The Hebrew Hammer 10]

I mentioned this in the I44 thread, but I don't think it has anything to do with that addon. I have two groups of about 35 men, named group1 and group2 respectively. They are both identical except for the fact that they have different names. For whatever reason giving them a command of {_x insertcodehere} foreach units group this hasn't been working. So individually I had to disableAI FSM, autotarget, target, and set their unitpos to up with each unit. The desired effect is that they charge fearlessly across open ground through machinegun fire and flak. Because if they stop they'll surely be killed. Both groups were given a move waypoint with a line formation and full speed. However only group1 actually moves. group2 moves to get all it's units into a line formation, and then stands there as artillery lands on them until they all die. I have tried making their group leader invincible, thinking he was simply killed at the start and the AI were confused. I enabled FSM, autotarget, and target for him, thinking maybe he wasn't able to order his units to move. I moved the group leader into the middle of the open ground, and his units ran up to him, and halted in line formation in the middle of the field.

I'm kind of at a loss of what to do here, I have one group doing exactly what I want it to, and the other with it's thumb up it's ass. Again they are identical except different group names.

I also have a trigger set up about 300 yards from the OPFOR position that enables all of the disabled features that were disabled for the movement to that area. If I disabled AI features and forced them to be standing in each individual activation line, do I need to reactive them by doing this:

{_x enableAI "FSM", _x enableAI "Target", _x enableAI "autotarget", _x setunitpos "auto"} foreach units group [b]group1[/b];

or does that need to be replaced with the unit name of the group leader? I just tried simply doing "group1 enableAI "FSM" etc, etc. and it didn't work.

[blackmamb 2]

I might be wrong now, but i believe that Arma generally doesn't like groups to be that big.

I myself usually never go with group bigger than 12 units.

As for your code, it'd be:

{_x enableAI "FSM"; _x enableAI "Target"; _x enableAI "autotarget"; _x setunitpos "auto";} foreach units group leader1;

Or just (and this is the one you want):

{_x enableAI "FSM"; _x enableAI "Target"; _x enableAI "autotarget"; _x setunitpos "auto";} foreach units group1;

Edited October 8, 2012 by BlackMamb
another error in the code

[The Hebrew Hammer 10]

Well that solves that.. I will try breaking it down into small units.

[blackmamb 2]

Post above edited. There was an error with the semicolons.

[The Hebrew Hammer 10]

eh, well I tried smaller groups, same effect. I'm running ASR_AI, tried removing that, still fucking useless. I am angry. I also tried the opposite, combining the groups. Seems that they just stood there again. Because fuck the waypoints right?

the code you posted worked fine though. I can't even get the AI to cross that phase line so it's pointless. I noticed when I took command of the advancing group, the group that previously would advanced, did not. There is more than enough room to maneuver.

Edited October 8, 2012 by The Hebrew Hammer

[zapat 56]

What is their CurrentCommand and expectedDestination after receiving the order but not moving?

I've had something similiar with ground vehicles recently, where expectedDestination didn't get filled. Then sooner or later, after issuing the same move order for a couple of times they eventually started.

[The Hebrew Hammer 10]

I'm unfamiliar with that but I will read into it. I recorded a video detailing the problem, maybe a visual will explain this better. They actually do move after about 5-6 minutes, but again they don't fucking engage, they don't crouch or go prone, even though I have clearly enabled those AI features via trigger.

[zapat 56]

You'd better get used to it: Arma editing is at least 30% bugfinding. Get better in this, and you'll progress a lot quicker.

First you need to pinpoint where the orders are jamming: do the units get them, but don't follow? Or they don't get them at all: why then? Is there something wrong with your commands, or the scheduled environment is so stressed theat the whole process is hallted for some seconds, etc...

Check every step in a modelled environment, and you'll se which is the problematic.

[kylania 568]

I never rely on AI doing anything I want them to. That way you're never disappointed when they don't and pleasantly surprised when they do. :)

[The Hebrew Hammer 10]

Would you recommend giving the group leader an activation of:

{_x disableAI "fsm"; _x disableAI "autotarget"; _x disableAI "target"; _x setunitpos "up"} foreach units group1

rather than using "this" over and over again in each individual's init? I've taken setting combatmode to blue out of the equation entirely, as it doesn't matter if the AI cannot target anything. To re-enable everything, I should be able to place a trigger activated by BLUFOR, and replace the code above with "enable" and "auto" right? I've set a trigger that's about 500 meters long, 10 wide as a phaseline that is supposed to reactivate all of the disabled features, and when BLUFOR actually does cross the phaseline, nothing changes.

The mission is entirely winnable by the BLUFOR, enough units survive the crossing to be combat effective. The units on the hill have superior positioning, but are entirely exposed while the BLUFOR can utilizing cover in buildings and micro-terrain. If the other side would charge at the same time it would also force the enemy to engage everything at once, meaning their firepower would be less concentrated.

Also minor question: If I gave the OPFOR a disableAI "move" command and the variable I used was "_x", I need to use something else for my BLUFOR guys right? I used "_1" for group1 and "_2" for group2 because I was getting weird behavior out of them while using "_x". I'm by no means that good when it comes to scripting, everything I know I've picked up by reading the forums over the past year or two.

Video I recorded:

http://www.youtube.com/watch?v=XN3FAA-pLz8&feature=plcp

Edited October 9, 2012 by The Hebrew Hammer

[zapat 56]

_x is a special variable, which means the current-element inside foreach, so this may not be qa minor question, but something that cause erratic behaviour!!

{

hint str _x;

} foreach [1,2,3];

will hint 1 then 2 then 3.

You cannot substitue it!!!! It must be _x, otherwise it won't have value.

The _x contains the current value from the nearest foreach block: a block is defined by { and }.

{_x disableAI "fsm";} foreach units group1;

will itinerate through all units of group1

{_x disableAI "fsm";} foreach units group2;

will itinerate through all units of group2

[The Hebrew Hammer 10]

Okay, I will give it a shot in the morning! I had always figured that was the case, but using "_x" was also giving me undesirable results, I figured I had to use different variables.

[zapat 56]

Use Player sidechat str _variable; if you are getting unexpected result, which are usually caused by coding errors.

This is the basic debugging step: you need to know where variables go off. They always do somewhere if something is not working. :)

[The Hebrew Hammer 10]

I changed it to "_x' the desired effect worked.

Still no change from my static units, I'm not sure how to troubleshoot that.

[twirly 11]

Have you tried smaller groups. Looks like you have about 40 in a group!

[The Hebrew Hammer 10]

I ran a test with smaller groups, and had no luck. What I've done as a temporary fix is add a trigger:

{_x doMove getmarkerpos "wp1"} foreach unit thislist

This forces the individual units to move. The problem is this takes away my ability to get them into a line formation, so it's a really large bunched up column of units, but when they get to the FLOT they start to disperse and engage.

[rejenorst 18]

I am sure you've tried this but thought I'd double check:

Hi Hebrew Hammer, have you tried moving the waypoints around a bit just incase the position is on a rock/static object? I have noticed that groups will sometimes fail to move if the waypoints are placed on objects such as trees/rocks etc.

You can also try and make two waypoints for each group.