Force AI units to stay away from a (trigger) area

[RicHornet 0]

In the past I found a script that forced certain types of AI units to stay away from a trigger area which I implemented in a mission.

Unfortunately I lost that mission files (including the script files) and despite my best search attempts, I wasn't able to find that same trigger and script.  

 

To be more precise what I would like is to have a trigger area in the map/mission where for example when any Red side aircraft or a certain model/type of aircraft enters this trigger area it is forced to turn away (like 180 degrees or so) and this way such units would avoid the same trigger area.

 

Thanks in advance for any replies.

[redarmy 420]

4 hours ago, RicHornet said:

In the past I found a script that forced certain types of AI units to stay away from a trigger area which I implemented in a mission.

Unfortunately I lost that mission files (including the script files) and despite my best search attempts, I wasn't able to find that same trigger and script.  

 

To be more precise what I would like is to have a trigger area in the map/mission where for example when any Red side aircraft or a certain model/type of aircraft enters this trigger area it is forced to turn away (like 180 degrees or so) and this way such units would avoid the same trigger area.

 

Thanks in advance for any replies.

Well what was the preceeding way you had your AI actually mobile to begin with? Editor waypoints(gaurd etc) ,something else?

Im guessing you probably had a script running this that created random waypoints for units and then whitelisted your trigger area/ marker area,if your remembering an instance of units "avoiding" an area.

 

You can look into invisible walls but it wont help with aircraft ("Land_InvisibleBarrier_F")

 

A hacky way off the top off my head that you could do it is by first off giving a variable name to the aircraft/s,then having a trigger that detected them inside it,then if condition true,setPos of the unit to somewhere else on map,with a setHeight command.

 

Name your enemy aircraft "Red1"  throw a trigger down with size needed

 

condition :

Red1 in thislist

On Activation:

Red1 setpos  getpos Hanger1; Red1 setpos [getpos this select 0, getpos this select 1, (getpos this select 2) +2000]

Give this a try. it should teleport your enemy aircraft named Red1,to the location with the object  "Hanger1" , and place it 2000 meters high. Place a hanger and call it Hanger1(or literally any object) and place it somewhere far from the area near the trigger ,or your general enemy airspace. Not tested though the idea should be pretty clear,never tried this before.

[RicHornet 0]

First of all thanks for the reply redarmy!

 

Well, the trigger and script that I had in the past didn't envolve any "teleport" and that would be a solution which I would like to avoid.

 

Basically what happened in the trigger and script that I had in the past was that if a certain plane type, let's say for example a "O_Plane_Fighter_02_Stealth_F" (which is the Stealth version of the To-210 Shikra) entered in the trigger area then it would turn back (was forced to do it) in a direction for example 180 degree or so from where it came from when it entered the trigger area. And I remember this was all done and happened naturally, with "naturally" I mean that the aircraft simply turned away and when or if it entered the trigger area again then the same thing would happen.

 

I hope that I've explained myself better this time?

[RicHornet 0]

Ok, I found a way to implement what I wanted. Probably this isn't the most "elegant" solution but I believe it's quite simple to implement in a mission since it "only" requires one (1) Trigger and one (1) Marker.

Basically the Trigger acts both as defining the no-go area and defines the code that forces some type of AIs to avoid the Trigger area. And the Marker serves as a "rallypoint" to where the AIs that shouldn't be allowed to enter the Trigger area will go after entering the same Trigger area. 

The example below prevents a group of OPFOR fixed-wing aircraft (planes) from entering the trigger area. I implemented this on a mission where I have a BLUFOR Carrier group with ships armed with SAM launchers and whose objective is to prevent the REDFOR from flying near or around the BLUFOR Carrier group ships and therefore ending up being shot down "like flies" (in this case the Trigger area will cover the areas around the Carrier group).

 

Trigger:

Define desired area (for example: A: 8000, B: 8000 and Ellipse)

Activation: OPFOR

Activation Type: Present

Repeatable (option ticked)

 

Condition: 

this and ({_x isKindOf "plane"} count thisList >0)

 

On Activation:

nul = [thisList] spawn {_thisList = _this select 0; _eplane = _thisList select 0; _epgrp = group _eplane; lepgrp = leader _epgrp;  { _x doMove (getMarkerPos "rpredair"); _x setBehaviourStrong "CARELESS"; _x flyInHeight 50; sleep 1; } forEach _thisList;};

 

On Deactivation:

lepgrp setBehaviourStrong "COMBAT"; 

 

 

Marker:

Choose pretended type of marker (for example: "Empty" marker)

Give it the variable name of:  rpredair

And place it in any desired location but of course outside and at least a little bit away from the Trigger area.

 

   

 

 

[RicHornet 0]

Well, in the meanwhile I found a better solution via a small modification of what I previously did and posted above and which is actually the solution which I was trying to and going after!

Basically, this new version doesn't require the Marker at all and works even better since in this example when a group of OPFOR aircraft reaches the "no-go" trigger area then these aircraft will turn 180 degrees away from the trigger area and this relative to the aircraft's approach angle. This brings a huge advantage since the aircraft will always turn 180 degree away from the trigger area independently from where they approach the same area, where in the previous version they didn't (previously, it basically only covered a "one side" approach regarding the trigger area).

 

Anyway, here's the example:

 

Trigger:

Define desired area (for example: A: 8000, B: 8000 and Ellipse)

Activation: OPFOR

Activation Type: Present

Repeatable (option ticked)

 

Condition: 

this and ({_x isKindOf "plane"} count thisList >0)

 

On Activation:

nul = [thisList] spawn {_thisList = _this select 0; _eplane = _thisList select 0; _epgrp = group _eplane; lepgrp = leader _epgrp; { _rallyp = _x getPos [2000, (getDir _x)-180]; _x doMove (_rallyp); _x setBehaviourStrong "CARELESS"; _x flyInHeight 50; sleep 1; } forEach _thisList;};

 

On Deactivation:

lepgrp setBehaviourStrong "COMBAT"; 

  

 

   

 

 

[pierremgi 4740]

NOTE: thisList refers to preset condition only . So, here OPFOR present.
When you add a condition:

this and ({_x isKindOf "plane"} count thisList >0)

you mean:  OPFOR present (this) and first OPFOR (vehicle(s) or infantry list) entered in trigger's area (within the trigger interval, set to 0.5 by default... then trigger is activated)...

who are plane(s) because you add the kind of objects in condition (OK).

As you can see this is useless here.

{_x isKindOf "plane"} count thisList >0   is enough.

 

When you pass thisList in activation code, you pass one or two OPFOR "plane", which entered during the trigger interval, but also all the OPFOR, infantry/"non-plane" vehicles, already entered before the trigger fires!. Perhaps it's what you need, perhaps not.

You can test it adding in condition field, before your condition : hintSilent str (thisList apply {typeOf _x});

and:  systemChat str (thisList apply {typeOf _x}) in activation field.

 

You can also try positioning ground OPFOR assets/infantry inside the area and see what happen when a plane enters the area.
 

Now, your activation code.

Your _ePlane is the first unit in thisList, so you be an infantry!  You define its group and the leader of the group...
But you don't do anything with that, just playing with _thisList... which "fortunately" includes all the passed list.

 

Your code is same as:

thisList spawn {{  _x doMove (_x getPos [2000, (getDir _x)-180]); _x setBehaviourStrong "CARELESS"; _x flyInHeight 50; sleep 1; } forEach _this};

but, if you don't want strange behavior with OPFOR infantry/ground vehicles, you need to select the "plane" again:

(thisList select {_x isKindOf "plane"}) spawn {{  _x doMove (_x getPos [2000, (getDir _x)-180]); _x setBehaviourStrong "CARELESS"; _x flyInHeight 50; sleep 1; } forEach _this};

 

Well... that's not what you need exactly. Despite a repeatable trigger, once your trigger is activated, the activation code runs with the present (this)List, so the further plane(s) entering trigger will not run the activation code. You need to de-activate et re-activate the trigger for taking into account the new entering plane(s).

One solution is to deactivate trigger, so it can be re-activated by any OPFOR plane... not already treated!

Try your code with multiple planes and see what happens.

 

Now, try, this activation code:

[thisList select {_x isKindOf "air"},thisTrigger] spawn { params ["_planes","_trig"];{_x setVariable ["passed",true]; _x doMove (_x getPos [2000, (_trig getDir _x)]); _x setBehaviourStrong "CARELESS"; _x flyInHeight 50; sleep 1; } forEach _planes};

 

For the deactivation field...  The code above deacts as soon as you treat planes (by the check of "passed" variable). So, you can't resume the combat behavior for the whole group, as some planes still can be in area. I let you think about that.

 

 

 

 

 

 

 

 

 

 

[RicHornet 0]

Quote

NOTE: thisList refers to preset condition only . So, here OPFOR present.
When you add a condition:

this and ({_x isKindOf "plane"} count thisList >0)

you mean:  OPFOR present (this) and first OPFOR (vehicle(s) or infantry list) entered in trigger's area (within the trigger interval, set to 0.5 by default... then trigger is activated)...

who are plane(s) because you add the kind of objects in condition (OK).

As you can see this is useless here.

{_x isKindOf "plane"} count thisList >0   is enough.

 

First of all, thanks for your reply and heads up!

 

Ok, so the "this" in the condition is redundant, I see. Thanks again for the heads up.

 

 

Quote

When you pass thisList in activation code, you pass one or two OPFOR "plane", which entered during the trigger interval, but also all the OPFOR, infantry/"non-plane" vehicles, already entered before the trigger fires!. Perhaps it's what you need, perhaps not.

 

That's why I use the {_x isKindOf "plane"} before count thisList >0, so that only aircraft gets into the list that is passed as a parameter to the script. What I want with my example is to create "air exclusion zone" (for aircraft only) if you will.

And yes, I tested it and it works just like I want. For instance I tested by sending an enemy wheeled armored vehicle (APC) into the trigger area and just like intended the enemy vehicle wasn't counted/considered and therefore it didn't turn away. But if I change to {_x isKindOf "car"} before count thisList >0 then it gets counted and the vehicle will turn away from the trigger area.  

 

 

Quote

Well... that's not what you need exactly. Despite a repeatable trigger, once your trigger is activated, the activation code runs with the present (this)List, so the further plane(s) entering trigger will not run the activation code. You need to de-activate et re-activate the trigger for taking into account the new entering plane(s).

One solution is to deactivate trigger, so it can be re-activated by any OPFOR plane... not already treated!

Try your code with multiple planes and see what happens.

 

Now, try, this activation code:

[thisList select {_x isKindOf "air"},thisTrigger] spawn { params ["_planes","_trig"];{_x setVariable ["passed",true]; _x doMove (_x getPos [2000, (_trig getDir _x)]); _x setBehaviourStrong "CARELESS"; _x flyInHeight 50; sleep 1; } forEach _planes};

 

For the deactivation field...  The code above deacts as soon as you treat planes (by the check of "passed" variable). So, you can't resume the combat behavior for the whole group, as some planes still can be in area. I let you think about that.

 

For my current situation/scenario, I only expect that a single group of planes (all from the same group) will ever enter the trigger area at one given time. For instance, I don't expect that two (2) different groups of planes will even enter the trigger area at the same or given time for my scenario. 

However your example made me think about the possibility of multiple groups of enemy aircraft entering the trigger area at the same time and I'll definitely take a look at your examples!