Switching AI units from one Side to another -> Getting "Non-Reactive" units?

[madrussian 347]

Hi all,

I'm encountering an issue moving men from the Civilian side to the West side via a join command.

The newly West side guys (completely unarmed) are generally detected by regular East side armed units, who gun them down with reckless abandon, as expected.

However, under certain conditions, the East units simply do not detect the West guys as enemy. (They glance at them but that's about it.) Likewise, the surviving newly West side guys do not react to the armed East units. All units are in plain view of one another. Now the gravity of the issue comes to light:

If I then give the surviving newly West guys (aka the "non-reactive" guys) a weapon/ammo, they proceed to gun down the all the armed East units, one at a time, while the armed East men just stand there staring back and die. As you can imagine, this is a big problem!

I'd really like to get to the bottom of this, because it's quite a powerful tool to be able to move AI from one side to another.

Now, I recall reading about a number of people encountering "Non-Reactive" AI units over the years, and posting about it. (Also, specifically seem to recall Silola had a similar issue at one point with DAC.)

OK, some questions:

1. How many of you have experienced "non-reactive" AI?
   
2. What causes it?
   
3. What are the known remedies?
   

Btw - I raised this very issue on a another thread located here. Afterwards it occurred to me, best to raise visibility with a dedicated thread, so more people may be helped/enlightened by discussion of this perplexing problem. [Also, would be very nice indeed if a kind BIS dev might drop in and enlighten us on how the AI threat detection routines operate, and why we might be getting "non-reactive" units due to a side-spanning join.]

Thanks all. :)

[avibird 1 154]

I never use the join command. This is how I do it

1. Go into the mission init sqf and change the side of the unit there. I never had an issue.

2. You can place a unit down make the presents set to zero with a high rank and then place the units you want down and group them. Never had an issue with this as well.

[madrussian 347]

Thanks AVIBIRD 1. I've used both of those methods for various purposes before. However, those work to get units of one side in the config placed on to another side, at mission startup. But they are a one shot deal that applies only to the initial side of a unit.

The intent here is to have units be able to switch allegiances on-the-fly mid mission. For example, to have civilians to take up arms and join the fight on one side or the other, based on some unfolding mission criteria. More specifically, I am having units created by the ambient civilian module (ALICE2), releasing from the system, and having them taking up arms to either join the players side or fight for the enemy, etc.

So we really do need the join command. Thus the need to avoid or otherwise overcome "Non-Reactive" units.

[twirly 11]

Look at this post here... http://forums.bistudio.com/showthread.php?133269-Make-Afrenian-Army-enemy&p=2133034&viewfull=1#post2133034

See if any of my little scripts there will help you.

[madrussian 347]

Nice little scripts twirly! Very concise and well written. :)

Unfortunately, the problem here revolves around the join command itself (which I see is at the heart of all three of your scripts).

I'm starting to realize what I've found is actually a bug in ArmA2, related to join which occurs and is 100% repeatable, but again under certain conditions, which I probably ought to elaborate on now. OK, here goes:

[bear in mind - This is strictly a test mission designed to root out this bug, not anything intended to be playable. Although it started out that way. :p ]

I start out with a town in Chernarus, Stary Sobor to be exact. I have a single group of 55 civilians. I detect all the buildings of type "house" within a 100 meter radius. I detect all AI door memory points on these buildings that ALICE1 would normally use as spawn points (i.e. "AIdoor%"). I create AI door objects on all these buildings via BIS_ALICE_fnc_doorCreate. I assign each civilian in the group a random AI door (which is really just an invisible vehicle that BIS came up with to simulate people going inside their house, when the house is a solid block). Then I order each civilian inside his door via the orderGetIn command. Once inside, I arm them with a weapon but no ammunition (simply so I can tell who went inside and who didn't). After a few seconds, they are ordered out of their AI door. So far so good.

Meanwhile, an East group with about 10 armed men from Novy Sobor has been moving in towards Stary Sobor. They are currently about halfway between the towns...

Back in Stary Sobor, each man is ordered out of his AI door, and instructed to move to the center of town. Shortly afterward (0.5 seconds to be exact), the man is ordered into a newly created West group, and he is set to never flee. All of these newly West men proceed towards the center of town.

Now, the armed East men show up. They kill most of the newly West guys (who recall have a weapon but no ammo), but completely ignore a significant percentage of them (aside from the glances, etc). This goes on indefinitely... the armed East men never acknowledge these surviving West men as a threat.

This problem is 100% repeatable.

Then at this point (mentioned previously on this and the other thread), I can do one of a couple of things:

1. If I give one of the west guys some ammo, he will begin gunning down the armed East men, one at a time, and without retaliation or evasive action on the part of the armed East men. <- This is the mission breaking aspect!
   
2. Instead, if I join the newly West guys to a newly created West group, the armed East guys open fire again and gun the remaining West guys down, to the man. (Note - 1 second delay from first join to second join is enough)
   

Here's the kicker though, if I do the two joins for each man (still a second apart) while he is inside his AI door, the end result is again numerous game-breaking "Non-Responsive" guys! Thus unfortunately, there appears to be no magic bullet to combat this issue, such as a simple "double join" that you can do anytime, etc.

After running this test with many, many, many variations over the past couple days, I am 99.9% sure of one thing:

This bug is directly related to the join command, and units going into vehicles (including but not necessarily limited to AI doors), and the timing of when the board, debark, and join(s) occur.

Another reason I am confident of this, is that if you simply plop down a civ group and a east group in the editor (facing off and in full view of one another), and join the civ guys to a newly created West group, the East guys will gun them all down, every time. It's only when you add in boarding/deboarding aspect that the "Non-Responsive" units start cropping up.

Wow, that was a mouthful. :)

Thoughts?

[cuel 25]

Tried joining grpNull before joining west/east groups?

[madrussian 347]

Good idea. I had thought of that too. I can join the civ guys to West, wait one second, then join again to West. Alternately, I can join the civ guys to grpNull, wait one second, then to West. Unfortunately both result in the same outcome(s) (per the description above). I'm pretty sure doing a join grpNull just creates a new group on the side that the units were on. So if you join Civilian guys to grpNull, the new group they end up on will be Civilian.

So the permutations look like this:

1. Civilian -> West -> West
   
2. Civilian -> Civilian (via grpNull) -> West
   

Anyhow they both seem to do the same thing. It really seems dependent on when the joins happen, in conjunction with when they board/deboard the vehicle (invisible AI doors in this case). The first join (based on the timing) is the culprit, forcing the units into "Non-Reactive" state. The second join remedies the non-reactive guys, but again it too only works (or doesn't work) based on the timing. (Also, the one second span between joins is pretty irrelevant I think.)

[b00tsy 28]

OK, some questions:

1. How many of you have experienced "non-reactive" AI?
   
2. What causes it?
   
3. What are the known remedies?
   

I am having similar issues too with a mission I am working on.

In my case I am working with opfor as player units and independents and civils as west side.

Even though the civils are set to be hostile (in the init) to opfor they do nothing except for aiming and crouching when they encounter opfor, and they have a guard/open fire waypoint too.

Also independents don't do a thing half of time except when you shoot a couple of them down, then they will start shooting back.

They don't behave anything like the defaut west vs east army units

[madrussian 347]

Interesting B00tsy. Curious, how are you setting the civils to hostile (in the init)? Assuming you are using join also? (Not anything with setFriend, right?)

Also the part about the independents not doing anything half the time at first, is strange indeed. You start them out in the editor as Independent and they never switch sides?

[b00tsy 28]

Looking into it further I notice that why it wouldn't work for me was my own error. I simply added side=WEST in the init of the unit, but that wont work apparently.

What i tried now and did work is this: Create a civil unit or group and group it with a Bluefor or Opfor unit and set the probability of presence of that unit to zero. My civil now shows up as a West unit with blue icon on the map.

Though the independent problem I had is something else. They are set to be friendly to nobody, yet they remain passive most of the time. I can walk right by them and nothing happens. With default opfor/bluefor you get attacked right away.

[oksman 37]

If you want units to be "neutral" put this into their init.

This setcaptive true;

if they have weapons they'll engage enemies but if they're unarmed they'll just panic and try and run.

To avoid that I'd put in 2 more lines into their init.

This setbehaviour "careless"; this setcombatmode "blue";

That's how I do it, hope it helped. Regards Oksman!

[madrussian 347]

Thanks for the tips Oksman. Turns out I'm dealing with a game bug here that's unrelated to setCaptive. Rather, this bug results from using the join command to move units from one side to another. In any event...

Good news! I've finally gotten to the bottom of exactly what causes "Non-Reactive" units when they undergo a side-spanning join! Also, I figured out how to prevent it! It's quite simple actually. Everything can be visualized in terms of two units, one vehicle, and these three diagnostic commands: countFriendly , countEnemy, and countUnknown.

First, here's how to simply and reliably generate game-breaking "Non-Reactive" units:

(Notes - During this procedure, don't set anyone as captive or otherwise deviate from these exact steps. Use a loop to poll countFriendly, countEnemy, and countUnknown on a 0.1 second basis.)

1. Create an unarmed Civilian side guy, and an armed East side man, each out of view of one another. [When polled via countFriendly , countEnemy, and countUnknown: The east man counts the civ man as unknown, which makes sense as again they don't yet see each other.]
   
2. Move the Civilian guy into the cargo space of a unmanned vehicle (can be any vehicle with cargo space), then move the armed East man to a position where he can plainly see the Civilian guy's vehicle. [When polled: The east man still considers the civ guy as unknown.]
   
3. Create a new West group via createGroup. Join the Civilian man to the newly created West group. (Note- The newly West guy is still cargo inside the vehicle, and the armed East man is still watching the newly West guy's vehicle.) [When polled: The east man still considers the civ guy as unknown.]
   
4. Order the newly West guy to debark the vehicle. Watch what happens next. When polled via countFriendly , countEnemy, and countUnknown: The armed East man (who plainly sees the newly West guy debark), will count the West guy as friendly! This should not happen!!! Instead, the East man should detect the West man as enemy, and open fire! (Note that the West man, though unarmed, in not captive...) At this point we have a "Non-Reactive" unit situation. As mentioned previously, if you give the unarmed newly West guy a gun/ammo, he will open fire on the errantly-passive armed East man, who will just sit there and passively become a bulleted pin-cushion.
   

That's the easiest way to reproduce this bug!

Now, here's how to prevent "Non-Reactive" guys from happening: You simply only perform side-spanning joins when units are on foot!

Here is that same procedure, only done with "Non-Reactive" prevention in mind:

1. Create an unarmed Civilian side guy, and an armed East side man, each out of view of one another. [When polled via countFriendly , countEnemy, and countUnknown: The east man counts the civ man as unknown, which makes sense as again they don't yet see each other.]
   
2. Create a new West group via createGroup. Join the Civilian man to the newly created West group. [When polled: The east man still counts the newly west man as unknown, as they still don't yet see each other yet.]
   
3. Move the Civilian guy into the cargo space of a unmanned vehicle (can be any vehicle with cargo space), then move the armed East man to a position where he can plainly see the Civilian guy's vehicle. [When polled: The east man still considers the newly west guy as unknown.]
   
4. Order the newly West guy to debark the vehicle. Now you get a reasonable and correct result: When polled via countFriendly, countEnemy, and countUnknown: The armed East man (who again plainly sees the newly West guy debark), will count the West guy as enemy. He will open fire and gun down the unarmed west man. No more "Non-Reactive" units! Everyone is behaving as they should.
   

Also, initial tests I've run indicate that you can indeed start with a Civ guy, join him to the West side, immediately setCaptive him, then later board him to a vehic as cargo, then debark him, and the good news is as soon as you make him non-captive, his enemies will shoot him per normal.

So it seems it all boils down to this golden rule:

If you want to join units from one side to another, make sure they are on foot first!

Also, make sure they are on foot for a number of seconds first, as you may recall that in my initial testing, if you do the join right after a debark, this can still result in "Non-Reactive" units.

Hope this helps at least a few of you out there. :)

[Dwarden 1125]

@MadRussion was this tested with latest 1.61 beta? (1.60.92767) ? and thanks for your effort

[twirly 11]

I just did a little test using beta 1.60.92767 and I would say that MadRussian is correct.

Little test here!

At the start of the mission civ1 is moved into the empty BMP3

Press 0-0-1 (Radio Alpha) to switch civ1 to West

Press 0-0-2 (Radio Bravo) to eject civ1 from the BMP3

Even though he is right in front of an East soldier.... nothing happens!!!!

Press 0-0-3 (Radio Charlie) to switch civ2 (who never entered a vehicle) to West.

He is shot immediately!!

EDIT:

If I switch civ1 to West again after he has left the vehicle.... only then is he shot. The thing is he was never West while he was in the vehicle.... my script checks for trying to switch the same side to the same side and will complain. It never complains!!... civ1 cannot be made to switch sides once he is in a vehicle.

Edited May 15, 2012 by twirly

[suma 8]

Sounds like an interesting issue.

Could the repro be scripted to save a programmer time while repeateadly executing it during debugging?

[madrussian 347]

@Dwarden & Twirly: Yes, I produced this result with 1.61 beta (1.60.92767).

@Suma: Absolutely, here is a quick automated example:

Non_Reactive_AI_Automated

Thanks for looking into this! :)

[madrussian 347]

Fixed: Joining unit in the vehicle to a different side group did not change the perceived side of the unit.

Very nice! Thanks Suma, Dwarden, and company for the fix! :)

And thanks Twirly for double-confirming the find with your test mission as well.

[kremator 1065]

Has it fixed your problem MadRussian ?

[madrussian 347]

Hi Kremator, regarding my ALICE2 Release Mechanism, yes this fixes my problem. (I was doing a workaround, but this fix allows for a much better solution.)

I am now in the process of gathering accurate dead-zone data for Chernarus. For some reason, sometimes the test subjects are grouping together in clumps in the middle of town (not proceeding to their individual destinations), thereby causing large swaths of errantly detected dead-zones (i.e. false-positives). I don't recall seeing anything like this on Takistan. Anyhow, I am going to experiment with multiple periodic doMoves, and see if that clears it up. Also adding some options to the dead-zone detection system, like being able to toggle markers on/off, etc. As soon as I get accurate Chernarus dead-zone data, I'll send you and Orcinus a quick beta of the system, and see what you think.

[orcinus 121]

Great stuff, excellent work by all concerned in fixing the bug - especial kudos to the devs for such a rapid response :D

Sorry I haven't got the Fallujah dataset yet, the last few weeks have been very busy with RL stuff. Will have that done by sometime over the weekend.

Looking forward to the beta!