Patrol and Convoy Qs

[Blitzen 10]

I got some questions for all you OFP gurus out there...

My first concern is how to make multiple patrols guarding different areas. What I usually do for patrols is use the system from the tutorial "Intelligent Patrols" over on the OFP editing site. For anyone not familiar with this system, it uses three triggers: one acting as a simple "enemy deteced trigger", one as a "guard" trigger, and one as a "return to normal" trigger. The entire system works by switching whether EnemyDetected is either true/false. For instance, if EnemyDeteced is true then the units guard a specific area, and if its false then they return to their patrol.

My main problem is that I want to use this system over multiple areas. However, if an enemy is detected in area A, it would trigger EnemyDetected as true for both area A and area B. How can I break up this system so I can use it over multiple areas?

My second issue concerns convoy. Specifically, how can I make a group of soldiers disembark from their trucks/apcs/etc. if they come under fire?

Thank you for your help!

[Pulverizer 1]

If it uses variables (EnemyDetected), simply alter them to EnemyDetected_A and EnemyDetected_B. Alternatively, you could sync triggers with the groups' WPs and maybe group the separate triggers to the groups too.

Link to sample mission or the tutorial would allow for a more precise answer.

To get units out of vehicles under fire, use enemy detected triggers with unassignVehicle etc. You should find the exact code with a search on these forums.

Edited September 27, 2010 by Pulverizer

[Blitzen 10]

If it uses variables (EnemyDetected), simply alter them to EnemyDetected_A and EnemyDetected_B. Alternatively, you could sync triggers with the groups' WPs and maybe group the separate triggers to the groups too.

Link to sample mission or the tutorial would allow for a more precise answer.

Here is a link: Intelligent Patrols

I do believe that it uses the enemydetected variable but I dont know how to add the Enemydeteced_A/B that you mentioned.

Thanks

[Pulverizer 1]

Repeat all the steps (or simply use copy/paste) for another towns, but use another variable name in place of enemyDetected. Eg:

EnemyDetectedDourdan in the triggers near Dourdan, EnemyDetectedTrinite in the triggers near La Trinite and so forth.

You can use any variable names, but it might help to use something self-explanatory.

[ww2weasel 10]

Another approach... This approach allows 1 set condition in a trigger to set off many very different interactions than the trigger was conditionally setup to handle. Thus stopping the need for many triggers.

This is an example on how to get AI to "anticipate" players movement.

So you know a player has to enter trigger 1 - but you might like a chance meeting on the way to trigger 2...

t1 = trigger <a Trigger named "t1">

_eb= <eb=group this --> in AI unit's init line.>

[_eb, 0] <this means group eb's very first waypoint.>

?_player distance t1 <= 50:[_eb, 0] setWPPos getPos t2,this doMove getWPPos [_eb, 0]

so all you do is move the AI's group waypoint and all the members will run to --> t2 --> Trigger named 2

this works well - as I've set up very competitive racing against AI.

And yes this script can be optimized further...

_racer = <name of AI unit>

_eb = <eb=group this --> in AI unit's init line.>

example script:

_racer = _this select 0

_eb= _this select 1

_racer setSpeedMode "FULL"

_racer setBehaviour "AWARE"

?!alive _racer:exit

#leg1

?_racer distance t1 <= 50:[_eb, 0] setWPPos getPos t2,this doMove getWPPos [_eb, 0],goto "leg2"

~3

?!alive _racer:exit

goto "leg1"

#leg2

?_racer distance t2 <= 50:[_eb, 0] setWPPos getPos t3,this doMove getWPPos [_eb, 0],goto "leg3"

~3

?!alive _racer:exit

goto "leg2"

#leg3

?_racer distance t3 <= 50:[_eb, 0] setWPPos getPos t4,this doMove getWPPos [_eb, 0],goto "leg4"

~3

?!alive _racer:exit

goto "leg3"

#leg4

?_racer distance t4 <= 50:[_eb, 0] setWPPos getPos t5,this doMove getWPPos [_eb, 0],goto "leg5"

~3

?!alive _racer:exit

goto "leg4"

#leg5

?_racer distance t5 <= 50:[_eb, 0] setWPPos getPos t6,this doMove getWPPos [_eb, 0],goto "leg6"

~3

?!alive _racer:exit

goto "leg5"

#leg6

?_racer distance t6 <= 50:[_eb, 0] setWPPos getPos t7,this doMove getWPPos [_eb, 0],goto "leg7"

~3

?!alive _racer:exit

goto "leg6"

#leg7

?_racer distance t7 <= 50:[_eb, 0] setWPPos getPos t8,this doMove getWPPos [_eb, 0],goto "leg8"

~3

?!alive _racer:exit

goto "leg7"

#leg8

?_racer distance t8 <= 50:[_eb, 0] setWPPos getPos t9,this doMove getWPPos [_eb, 0],goto "leg9"

~3

?!alive _racer:exit

goto "leg8"

#leg9

?_racer distance t9 <= 50:[_eb, 0] setWPPos getPos t10,this doMove getWPPos [_eb, 0],goto "leg10"

~3

?!alive _racer:exit

goto "leg9"

#leg10

?_racer distance t10 <= 50:[_eb, 0] setWPPos getPos t11,this doMove getWPPos [_eb, 0],goto "leg11"

~3

?!alive _racer:exit

goto "leg10"

#leg11

?_racer distance t11 <= 50:[_eb, 0] setWPPos getPos t12,this doMove getWPPos [_eb, 0],goto "leg12"

~3

?!alive _racer:exit

goto "leg11"

#leg12

?_racer distance t12 <= 50:[_eb, 0] setWPPos getPos t0;this doMove getWPPos [_eb, 0],exit

~3

?!alive _racer:exit

goto "leg1"

Edited October 1, 2010 by WW2Weasel

[Blitzen 10]

Another approach... This approach allows 1 set condition in a trigger to set off many very different interactions than the trigger was conditionally setup to handle. Thus stopping the need for many triggers.

This is an example on how to get AI to "anticipate" players movement.

So you know a player has to enter trigger 1 - but you might like a chance meeting on the way to trigger 2...

t1 = trigger <a Trigger named "t1">

_eb= <eb=group this --> in AI unit's init line.>

[_eb, 0] <this means group eb's very first waypoint.>

?_player distance t1 <= 50:[_eb, 0] setWPPos getPos t2,this doMove getWPPos [_eb, 0]

so all you do is move the AI's group waypoint and all the members will run to --> t2 --> Trigger named 2

Okay, this is about all I understood...:butbut: However, that does seem quite useful and using functions such as distance greater/less than X as well as getpos "player" are the types of things that Im hoping to use to make missions without cluttering everything up with waypoints

[ww2weasel 10]

Yes the other thing I forgot to mention is waypoints will time out after a predetermined amount of time. So by moving a waypoint it actually reactivates it. Not sure if you noticed if you use a seek and destroy waypoint - after a period of time - the waypoint will time out. Also by using & moving a single waypoint you do save yoursef lines of code in a script. And by using the switch properties in a trigger your functionality can increase 10 fold. Just remember to use the appropriate number for the waypoint your using. [_eb, 0] [_eb, 1] [_eb, 2]