Scripting help, spawned fighter group ignore CAP/Fighter Sweep engagedist parameter

[Wizard1393]

Hi,

 

I'm trying to spawn a red fighter group of 2 MiG-29A's and have them go to a waypoint which is in the "players" CAP area.

I want them to have an Engagement distance of 50nm so I've set that in the task.

When they reach their waypoint they should orbit there, engaging anything that comes within 50nm, then RTB at bingo.

 

This works fine with a predefined group in the mission editor. But not when spawned dynamically.

The fighter group is spawned in around 80-110nm away, but they almost immediately climb to 30k+ ft, goes full AB and pushes towards the blue Awacs or tanker which is 100nm+ away.

 

Perhaps I'm doing something wrong in my spawning.

Does anyone have any guess as to why this happens?

[Zeagle]

It would be helpful if you explained how you are spawning this group. Are you using MOOSE? Also, a mission file would be nice. What does your template flight look like?

[toutenglisse]

Hi! sorry I can't help but interested in topic.

I can only think about workarounds... (with flaws, using ROE and mist.flagFunc.units_in_moving_zones - so Migs will only engage when blue group is inside moving zone, but won't prevent Mig group to eventually split and engage both player and long range detected awacs - here setting blue awacs/tanker invisible between ROE change and Mig group destroyed can be a workaround)

 

Is CAP selected as role for Migs ? (do removing CAP help task with 'MaxDist' or 'zoneRadius' to work? - if you use 'EngageTargets' or 'EngageTargetsInZone' task - I also suspect that attributes don't always have same meaning between a task in M.E. and in external script).

 

EDIT : removed wrong comment about "Orbit" task.

[Wizard1393]

I'm spawning it via mist.dynadd(groupTable)

 

GroupTable:

 

local tblGroup = {}
tblGroup =
{
["country"] = 'Syria',
["category"] = 'AIRPLANE',
["units"] = tblUnits,
["name"] = 'Red Fighter Group',
["route"] = tblRoute,
["task"] = "CAP",
["taskSelected"] = true,
}

 

Unit Table (tblUnits):

 

local tblUnits = {}
local intUnitNum

for intUnitNum = 1, 2 do

tblUnits[intUnitNum] =
{
["name"] = 'Red Fighter Unit ' .. msn.funcNextRedUnitNumber(),
["type"] = "MiG-29A",
["payload"] = msn.cap_SpawnFighterGroup_payload(),
["skill"] = "Random",
["onboard_num"] = "10"..intUnitNum,
["alt"] = 1000,
["alt_type"] = "BARO",
["x"] = spawnPoint.x+spawnDist,
["y"] = spawnPoint.y,
["speed"] = 210,
}

spawnDist = spawnDist + 100

end

 

Route Table (tblRoute):

 

local wpt2Point = mist.utils.vecToWP(trigger.misc.getZone('Objective Zone').point)
local tblRoute = {}
tblRoute =
{
["points"] =
{
[1] =
{
["alt"] = 1000,
["action"] = "Turning Point",
["alt_type"] = "BARO",
["speed"] = 210,
["task"] =
{
["id"] = "ComboTask",
["params"] =
{
["tasks"] =
{
[1] =
{
["enabled"] = true,
["key"] = "CAP",
["id"] = "EngageTargets",
["number"] = 1,
["auto"] = true,
["params"] =
{
["targetTypes"] =
{
[1] = "Air",
}, -- end of ["targetTypes"]
["maxDist"] = 83340,
["priority"] = 0,
}, -- end of ["params"]
}, -- end of [1]
[2] =
{
["enabled"] = true,
["auto"] = false,
["id"] = "WrappedAction",
["number"] = 2,
["params"] =
{
["action"] =
{
["id"] = "Option",
["params"] =
{
["value"] = 2,
["name"] = 1,
}, -- end of ["params"]
}, -- end of ["action"]
}, -- end of ["params"]
}, -- end of [2]
[3] =
{
["enabled"] = true,
["auto"] = false,
["id"] = "WrappedAction",
["number"] = 3,
["params"] =
{
["action"] =
{
["id"] = "Option",
["params"] =
{
["value"] = true,
["name"] = 15,
}, -- end of ["params"]
}, -- end of ["action"]
}, -- end of ["params"]
}, -- end of [3]
[4] =
{
["enabled"] = true,
["auto"] = false,
["id"] = "WrappedAction",
["number"] = 4,
["params"] =
{
["action"] =
{
["id"] = "Option",
["params"] =
{
["value"] = 2,
["name"] = 0,
}, -- end of ["params"]
}, -- end of ["action"]
}, -- end of ["params"]
}, -- end of [4]
}, -- end of ["tasks"]
}, -- end of ["params"]
}, -- end of ["task"]
["type"] = "Turning Point",
["speed_locked"] = true,
["y"] = spawnPoint.y, --var I send to the function that create the route table
["x"] = spawnPoint.x, --var I send to the function that create the route table
}, -- end of [1]
[2] =
{
["alt"] = math.random(3000,7000),
["action"] = "Turning Point",
["alt_type"] = "BARO",
["speed"] = 210,
["task"] =
{
["id"] = "ComboTask",
["params"] =
{
["tasks"] =
{
[1] =
{
["enabled"] = true,
["auto"] = false,
["id"] = "Orbit",
["number"] = 1,
["params"] =
{
["altitude"] = math.random(3000,7000),
["pattern"] = "Circle",
["speed"] = 150,
}, -- end of ["params"]
}, -- end of [1]
}, -- end of ["tasks"]
}, -- end of ["params"]
}, -- end of ["task"]
["type"] = "Turning Point",
["ETA_locked"] = false,
["y"] = wpt2Point.y,
["x"] = wpt2Point.x,
["speed_locked"] = true,
}, -- end of [2]
}, -- end of ["points"]

}

 

 

 

[Zeagle]

I use MOOSE for this. It's literally a couple lines of code with a template flight (late activation).

[Wizard1393]

I use MOOSE for this. It's literally a couple lines of code with a template flight (late activation).

 

Do you get dynamically spawned AI aircraft to follow a specific route (waypoints) and route (waypoint) actions with moose?

[Grimes]

It is still advantageous to know what exactly any sort of wrapper script is sending the scripting engine.

 

 

As for why its not working, I'm not sure. It appears you are just taking a task as generated by the editor and copying it to your script, which is usually extremely reliable and a great "starting off point" for modifying a task via scripting. Only thing I am curious about is if in your testing the ME placed group had roughly the same exact waypoint positioning as the spawned group. I say that because there is a known behavior of the maxDist setting where it doesn't apply to where that group is right now, but to any point throughout their route. So if that enemy awacs was ever with 50nm of the route they would see it as a valid target to engage.

 

 

 

 

Is CAP selected as role for Migs ? (do removing CAP help task with 'MaxDist' or 'zoneRadius' to work? - if you use 'EngageTargets' or 'EngageTargetsInZone' task - I also suspect that attributes don't always have same meaning between a task in M.E. and in external script).

 

Attributes have the same meaning, but you have MUCH more flexibility with the scripting engine in this regard compared to the editor. This flexibility is entirely down to

1. Editor doesn't list all attributes. For example the editor just has "fighters" and "bombers" for airplanes, but you can specifically tell a flight to only hunt AWACs, tankers, transports etc if you wanted to. This is extremely useful with SEAD tasks because you can just give AI a task to engage search and tracking radars but to ignore the launchers.

2. You are not limited to the scope of attributes allowed for a given task. For example if you wanted a flight to self escort you can allow AI to engage fighters at longer distances but still target sams or ships within the same task.

[toutenglisse]

There is something that I noticed and is maybe related to your issue, but big chance that it's bs sorry...

When I was trying to make dogfight script (with enemy aggressor spawning in front of player 5km away, same alt, with opposite heading) I noticed that point[1] coord ["x"] and ["y"] relative to aggressor's spawnpoint are ok when fed with spawnpoint.x and spawnpoint.y, but point[2] relative to player's position need to be fed with position.x for [x] and position.z for [y] (and not position.y).

(in my code for point[2] it is :

["y"] = mist.getLeadPos('Blue F18c 1').z,

["x"] = mist.getLeadPos('Blue F18c 1').x,

) if using .y for ["y"], the point was not good and aggressor's direction was false (note : player is invisible to aggressor as a threat until merge), while when using .z aggressor's direction was good toward player.

If you are having a similar issue, with your "wpt2Point" not being where expected because same shift between .y and .z, maybe it can be a cause to awacs/tanker being inside engagement zone ? If so try with : ["y"] = wpt2Point.z,

[Wizard1393]

It is still advantageous to know what exactly any sort of wrapper script is sending the scripting engine.

 

As for why its not working, I'm not sure. It appears you are just taking a task as generated by the editor and copying it to your script, which is usually extremely reliable and a great "starting off point" for modifying a task via scripting. Only thing I am curious about is if in your testing the ME placed group had roughly the same exact waypoint positioning as the spawned group. I say that because there is a known behavior of the maxDist setting where it doesn't apply to where that group is right now, but to any point throughout their route. So if that enemy awacs was ever with 50nm of the route they would see it as a valid target to engage.

 

 

Yes, it's basically copied from the mission file the ME generated and then adjusted, (some non-critical stuff omitted, some changed to vars etc.)

In my test, no, the ME placed MiG was not exactly in the spawnzone for the script-spawned migs. But it was closer to targets as I recall it, within 70 miles or so. Spawnpoint for script spawned red CAP is around 80-100 miles.

But spawned red MiGs almost immediately see the orbiting blue awacs and escort fighter from 120-ish miles away, goes full AB and climbs to 30k+ feet.

 

I'm curious too though about what you wrote about the bug. Can it be so, that because the MiGs eventually will (if not contested) end up within 50 miles of the blue AWACS orbit point, they engage right away?. It's in their route to end up close enough to engage.

 

@toutenglisse My script gets the point from a zone point so it doesn't have the altitude coord. Also I know my coords work since they fly the route normally when there's nothing to engage.

[Wizard1393]

@Grimes Wow, just wow. I applaud you. Grimes the script ninja strikes again. That is it, tested now with the red cap point 55 miles away from the blue awacs orbit point (MaxDist set to 45nm) and they do not engage. Wow this bug is bad. That removes the use (for me) of the MaxDist setting almost entirely. I like dynamic and unpredictable content. This bug makes my mission more static :(

 

EDIT: So wait. The spawned red AI MiG's in this case can only have this MaxDist bug "apply" on ME created assets then right? I have a few ME placed flight such as AWACS and tankers, if I made all blue flights spawned the bug is not there you think?

 

EDIT2: And you say that it's a "known behavior"? So it's not a bug? Thats weird. This is so far from what you think the MaxDist setting would do. You easily assume if at any time during the flight, an enemy aircraft comes within MaxDist setting, it will engage. Not "if blue flight wpt/leg is closer than MaxDist to red flight wpt/leg" engage at any distance... how'd did they even come up with this?

[Grimes]

I've reported it as a bug a couple years ago, I think Mbot might've posted the original report on the forums. Its one of those things I'm not sure if the behavior had changed at all or if this is indeed the intended behavior. For instance it would be kind of annoying if it was a "max dist from self" check that could result in the AI constantly discovering and chasing new targets. Granted they'd likely die before they get that far. The point is to restrict where it is allowed to attack. Right now that means its only checking the distance along a given route, it should do that, but also check distance from self and only attack if both conditions are met. At least thats what I think it should do.

[Wizard1393]

I've reported it as a bug a couple years ago, I think Mbot might've posted the original report on the forums. Its one of those things I'm not sure if the behavior had changed at all or if this is indeed the intended behavior. For instance it would be kind of annoying if it was a "max dist from self" check that could result in the AI constantly discovering and chasing new targets. Granted they'd likely die before they get that far. The point is to restrict where it is allowed to attack. Right now that means its only checking the distance along a given route, it should do that, but also check distance from self and only attack if both conditions are met. At least thats what I think it should do.

 

You are absolutely right. I get it now. You need to checks, one that checks MaxDist from route so they won't stray for too far, and also one for checking MaxDist from self.

That way you can say "Go max 60 miles away from route, but also only engage targets within 30 miles from self.

 

 

[Mr_sukebe]

I can’t comment on scripting, but if you were setting up that CAP flight in the Mission Editor, remove the CAP task and replace with search and engage within a zone

[Wizard1393]

I can’t comment on scripting, but if you were setting up that CAP flight in the Mission Editor, remove the CAP task and replace with search and engage within a zone

 

Yes. I'm going to try this as well, although with scripting, and see what the result will be, if they rush from 100+miles away to engage something that's in the engagement zone.

I'm also wondering what the engagement distance is. I'm thinking there must be one, under the hood somewhere, concealed from scripting.

I mean, otherwise any AI CAP flight with AWACS support would fly hundreds of miles to engage any enemy aircraft...

[Zeagle]

 

Do you get dynamically spawned AI aircraft to follow a specific route (waypoints) and route (waypoint) actions with moose?

 

yes

 

[Wizard1393]

 

yes

 

Cool. Yeah I've fiddled some with Moose some year ago and it's a powerful framework. I just never got around to getting myself really into it and learning it's functions.

Also, like Grimes kind of said, when your result (e.g. AI behavior) is not what you intended, it's so much harder to know if it's the wrapper code (e.g. Moose) or the SSE itself not doing what you expect.

The native SSE I understand and know my way around. Thats why I keep using it in conjuction with the excellent MIST library. Force of habit I guess :)

[Zeagle]

Yeah I agree. Moose is good though. I find that it generally works pretty well. Sometimes the documentation is lacking, which can be very frustrating. But overall I like it. I come from a programming background and prefer lower level as well. But I really need to learn more about the SSE and LUA.