Terminator357 Posted January 6, 2024 Posted January 6, 2024 (edited) I'm working on a SP Combined Arms mission in the ME. Multiple armored columns and a string of successively spawned A10's to attack them. I'm struggling to figure out why my CAS flights are only sometimes performing the "Attack Group" command I give them. Basically the attack is this: Once you've knocked out the SA-19, go in and drop a single CBU-97 on the lead vehicle in the column, attack from the East and above 6000 ft (1800 m)' I use "Unit in Zone" in the ME to trigger the attack. Either with the below script in a "Do Script" action, or through Triggered Actions with a "Perform Task" > "Attack Group" set to the above parameters. Both work, but not every time. I use a 'Message to All' command to validate that the conditions are being met every time, but the attack does not occur every time. Sometimes the plane will adjust its course and altitude to match the attack parameters then drop the bomb exactly as ordered, but most of the time the plane just keeps lazily flying along. After a minute its basic "CAS" AI takes over and the plane will engage in some attacks that I did not tell it to make (wrong direction, wrong altitude, wrong weapon) I don't know for sure, and can't find anything to prove it, but I think it has something to do with how the game prioritizes the AI's task que. Why else it would act like it got triggered, but then go off and do some other rando CAS attack? There's all kinds of activity going on in the mission and I do have about 10 other Triggered Actions besides this attack in the plane's waypoint actions...usually after 2 or 3 passes doing CAS attacks I did not tell it do, it gets around to the one I did tell it to do. Basically, I'm trying to make this attack trigger immediately when the conditions are met but the game is acting like it will get to it whenever it dam well feels like So, is there a queuing that takes place once a Task is pushed to the AI for a given plane? My understanding is that PushTask (especially through a script) is a 'right now' kind of thing. Like it's supposed to go to the front of the task list ahead of everything else. Is it possible that the AI could pick some rando CAS target(s) before my trigger sets itself and so decide that's it's going to finish doing whatever rando CAS things it's doing before it gets to my attack? Not sure what I'm looking for here beyond understanding how AI is prioritizing a target that's been pushed to it even if it has other targets already picked out. Any thoughts? ...I've tried using the below script in a triggered action "Perform Command" > "Run Script", but it never seems to work when I do it that way. Works fine as a "Do Script" trigger tho. local Target = {} Target.unitId = Group.getByName('Red Armor 1'):getUnits()[1]:getID() Target.weaponType = 256 Target.expend = "One" Target.directionEnabled = true Target.direction = 1.57 Target.attackQtyLimit = true Target.attackQty = 1 Target.altitudeEnabled = true Target.altitude = 1828 local fire = {id = 'AttackUnit', params = Target} Group.getByName('Blue CAS 1'):getController():pushTask(fire) [edit] to fix 'direction' ...should be in radians, not degrees. Edited January 13, 2024 by Terminator357
Terminator357 Posted January 9, 2024 Author Posted January 9, 2024 K, this is probably already covered somewhere else in this forum or Reddit but I can't find it after 4 days of reading so... This was all tested using the game's CAS AI in an A10 and F16, YMMV when applying the logic to CAP, SEAD, etc. You have two kinds of 'Tasks': The ones that are inherent to the game's basic AI. So if 'CAS' then actions like finding and shooting at targets and making radio calls are "AITasks". (https://wiki.hoggitworld.com/view/DCS_func_pushAITask) If you just put an A10 out there w/ a 'CAS' mission type, waypoints, weapons, and some bad guys in the vicinity, but no triggers to control anything, the plane will find and attack the bad guys. This is the 'CAS' AITasks doing their thing. Then there's every other Task. Basically, any task you assign the aircraft mid-flight via Push Task script, waypoint action, or trigger. (https://wiki.hoggitworld.com/view/DCS_func_pushTask) There are probably exceptions, but the basic behavior for prioritizing AITasks vs. (pushed) Tasks appears to be that any pushed task that is currently in progress (bombing run, missile attack, etc) will always be immediately superseded (pushed) by a new Task...so a new pushed Task will always end an existing pushed Task and start the new pushed Task right away. Pushed Tasks do not appear to immediately supersede AITasks. In these cases the game will finish the current AITask THEN immediately engage in the pushed Task. So if you can't figure out why your AI pilot appears to ignore your trigger/script to perform a specific attack, it's not ignoring it, it's just queuing it up in the #2 spot on its "things to do" list because it's trying to finish something the core AI told it to do first. You can work around it by deleting the mission type (CAP, CAS, etc) from the advanced waypoint actions. Now every task you push will immediately respond, of course you'll probably need to do a lot more triggering/scripting to setup your mission. This has become more of a problem as I've gotten more into map making and scripting. Really unhelpful in combined arms where some attacks can take a long time to execute, basically shutting down the effected AI unit(s) for new commands until it's done with whatever the AI told it to do. Can also lead to some unfortunate outcomes...like AI pilots flying directly into a storm of .50 cal machine guns at 1000 ft because your fancy attack trigger that told it to attack from 10000 ft was still waiting its turn
Grimes Posted January 10, 2024 Posted January 10, 2024 trigger.action.pushAITask and Controller.pushTask do effectively the same thing, the difference is in how the it gets the task. pushAiTask has to be a predefined task in the "triggered actions" task table within the group. IIRC it is literally what the mission editor trigger "AI Task Push" uses. In either case there is a task queue the AI have, sometimes they can have multiple simultaneous tasks, but the queue is still respected. pushTask will always push the passed task to the top of the queue, whatever rules exist for how the AI execute that task will impact when the task ends and the queue continues. With the task queue for instance if you have a search then engage task limited to tanks and another search then engage task only attacking sam sites, if the group was trying to attack the sams and then detected a tank, they will break off the attack on the sam and go for the tank. Yes attackGroup and attackUnit should be a top priority when pushed and force the AI to know about the targets. Without seeing the mission its difficult to know precisely why it can be unreliable for you. Best guess is the AI decide for one reason or another it can't execute the task. Once they abort that task the task is ended and it goes to the next task in the queue, which is likely that CAS task. Sidenote: CAS, SEAD, CAP, etc are all search then engage tasks with specific parameters you can't change. Deleting the default task is usually helpful because it helps control where AI will be and what they are doing. Could also try changing reaction to threat settings. Unfortunately we don't really have access to any useful debugger giving precise indications of which task the AI are on or why a task was ended. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum
Terminator357 Posted January 12, 2024 Author Posted January 12, 2024 (edited) Took me a few days to see this, thanks for the info. I'd just come back here to update the thread with some second thoughts on deleting the "CAS" task. After a lot of working on this the only tasking conclusion I can come to is that no matter how I work this I seem to break something. Basic gist of the mission is a crossroads defense. Multiple successive incoming armor columns that can stop and start up again based on random events. I've been trying to set it up such that the AI CAS flights will recognize if a column is moving or stopped, then drop a CBU on either the lead vehicle of a moving column, or the center vehicle of a stopped column, both from a specific direction and altitude. I just keep repeating this attack pattern until the plane or the armor is dead. With "CAS" enabled it mostly works, but the AI-Tasking sometimes makes the plane do oddball things...like drop the CBU just as the script directs, head-on approach from 7k ft at the correct vehicle, then immediately launch into a dive directly at the tank column as soon as the bomb releases. Always ends up well below 2k ft and cut to ribbons by AAA. With "CAS" disabled it all works mostly like I want, but for more oddball reasons (that I just don't understand) the AI will follow the attack profile perfectly...then fly right over the armor column without dropping the bomb. And not just once, but multiple passes like this until I just quit the game and go back to trying to figure out what I'm doing wrong I got to thinking that perhaps deleting the CAS AI also deleted some controller function or another that 'Attackgroup' or 'Attackunit' relied on...I dunno, grasping at straws with this one. I got similar logic working great for artillery (find stopped armored column, attack lead vehicle), but this CAS thing is kicking my butt. I the end I suspect you're right about the AI just deciding it can't execute a given attack, most likely because I've set it up so it can't. Edited January 12, 2024 by Terminator357
Tippis Posted January 12, 2024 Posted January 12, 2024 (edited) 44 minutes ago, Terminator357 said: With "CAS" disabled it all works mostly like I want, but for more oddball reasons (that I just don't understand) the AI will follow the attack profile perfectly...then fly right over the armor column without dropping the bomb. And not just once, but multiple passes like this until I just quit the game and go back to trying to figure out what I'm doing wrong Depending on the exact way this plays out, a common cause for this is that you haven't given the AI enough of a run-in so it decides that it's not in release parameters for reasons only the local AI divinity can fathom. If this is the case, then the AI will usually do the overflight and then go (far) out to reposition and re-attack. To make it attack on the first run, you have to give it a lot of space to come in — and preferably from the perfect angle. Think 40nm between the IP and the target waypoint. Less so with “Attack Unit”, but with the “destroy in zone” tasks, it will also occasionally decide that it must stick very close to that zone and will never fly far enough out to give itself the long run-in it needs to be able to drop, so you have to expand the zone a bit just to slap some sense into the AI. If the AI doesn't do the whole circling around to re-attack according to its own eclectic taste — which it sounds like you're experiencing — odds are that it determines the entire attack to be impossible for some reason or another, so it's only really following the waypoints as part of the flight plan. “Wrong” altitude is a common cause for this behaviour, and good luck figuring out what “correct” altitude will satisfy the picky bastard. I haven't seen it happen in a way that clearly shows the logic behind it, but I wouldn't be surprised if the AI can be equally picky about attack angle for some silly reason. The reason it occasionally works better with the CAS task set is that it makes the AI a lot more aggressive and opportunistic in its target picking. The original plan might still technically fail under the hood, but the CAS task dictates to the AI that, according to a different logic, it should attack this very opportune target that you've line up for it. But the price you pay for that is that, as Grimes says, you now have an AI preset to a bunch of behaviours that you can't really control, so it will often do very stupid things without you being able to stop it. All of this is also why the “destroy in zone” tasks often yield better results: you give more control to the AI to satisfy its own needs, but of course, you're now targeting a large (predefined) area rather than any specific unit. Edited January 12, 2024 by Tippis ❧ ❧ Inside you are two wolves. One cannot land; the other shoots friendlies. You are a Goon. ❧ ❧
Grimes Posted January 12, 2024 Posted January 12, 2024 The general problem with the "role tasks" like CAS, CAP, etc is that they have no limits. Its more a problem with threats that are actively detecting the AI like aircraft radars, sams, and ships. With the task active the AI are allowed to attack any valid targets anywhere on the map. That is why people often suggest using the "search then engage" tasks because it allows limits to be set. Be it distance from the route given, targets in a specific area, or specific groups/units. 1 hour ago, Terminator357 said: With "CAS" enabled it mostly works, but the AI-Tasking sometimes makes the plane do oddball things...like drop the CBU just as the script directs, head-on approach from 7k ft at the correct vehicle, then immediately launch into a dive directly at the tank column as soon as the bomb releases. Always ends up well below 2k ft and cut to ribbons by AAA. If you are using the same task from your first example then the moment the bomb gets dropped the attack task ends because you told them to drop only one bomb and make one attack run. Task ends it reverts back to CAS or whatever other tasking. It detects and decides to engage another target the moment it is "released" from the task holding it up, which means it has to get from where it is now to where it can actually attack its new desired target. I've seen AI run into their own bombs plenty of times because they simply decide they need to get down there. Could try setting attack quantity to 2 so that it does 1 pass and still thinks it needs to attack the target again when the bomb is released. If the target is destroyed on the first attack then it will abort the 2nd attack. Though if the target isn't destroyed on the first pass then AI will make another attempt. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum
Terminator357 Posted January 13, 2024 Author Posted January 13, 2024 1 hour ago, Tippis said: Depending on the exact way this plays out, a common cause for this is that you haven't given the AI enough of a run-in so it decides that it's not in release parameters for reasons only the local AI divinity can fathom. If this is the case, then the AI will usually do the overflight and then go (far) out to reposition and re-attack. To make it attack on the first run, you have to give it a lot of space to come in — and preferably from the perfect angle. Think 40nm between the IP and the target waypoint.... Ya know, I've encountered problems with run-in length before so I knew that and even thought I had accounted for it in this mission. The main battle space is only about 20 nm across, I had given the CAS planes an orbit waypoint about 7 nm away from the center of the action, this is where they were getting most of their attacks calls from. Decided to push the orbit out to 10 nm away and deleted the CAS profile...Wouldn't you know it, the plane starts behaving exactly as planned. * Plane hangs around at waypoint * Plane spots moving column->Plane bombs lead vehicle * Plane spots stopped column-> Plane bombs center vehicle. Rinse and repeat All within specified attack parameters...Perfect Can't believe it was that [slaps forehead] Ah well, learned a few new scripting tricks so not a complete waste of time. Thanks for the help, sir. 1
Terminator357 Posted January 13, 2024 Author Posted January 13, 2024 1 hour ago, Grimes said: I've seen AI run into their own bombs plenty of times because they simply decide they need to get down there... LOL! ...So, I had never seen such a thing happen before, but I had it happen a couple of times this past week as I've tested this. Been using the [F6] camera a lot to check the exact targeting of the bombs and a couple of times as I followed them in the plane flew right into my view, clipped the bomb, then both blew up and rained debris all over the armored column. Too funny.
Recommended Posts