Terminator357

Thanks. My mission is set up to behave much the same way your example is except that I used scripts and ME triggers in combination because it's just easier for me when there are several planes that will carry out the same tasks. Your aircraft RTB's when you'd expect it to (all ground targets gone) and I think mine is doing the same, but I have new ground units spawning in randomly so I need the aircraft to hold its station even when there are no targets presently available...Or at least force him to turn back to his orbit point after he's decided to RTB, but that bit has been a tough nut to crack.

Thank you, sir. So, after 3 days of testing I finally concluded that the planes weren't going RTB because their targets were dying before the attack could finish. They were going RTB because the abbreviated attack runs didn't allow enough time for a flag I'd set 50-odd triggers earlier to be reset by the time the aircraft reached the zone that assigns a new attack. Basically they were hitting their last waypoint and failing the assignment of another task, going RTB by default. That was fixed by making the flag I mentioned reset sooner. I have an "Orbit" assigned to that last waypoint but in some cases the plane still ignores it and goes RTB. That might be because sometimes there are no targets to assign until new ones spawn in, but it could be something else entirely too, I dunno. I kept up the testing until I got burned out trying to figure it out. Any kind of 'task' seems to be glitchy when it comes to forcing an RTB plane to go back to a previous waypoint. 'Push', 'Set', or 'Reset' just kept causing problems no matter how I tried to que up waypoint tasks with them. Interestingly enough 'setCommand' works ok. By 'ok' I mean the plane would receive the command en route to the airport, then when the gears went down and it was ready to turn in on final, it would pull the gears back up and turn toward the specified waypoint...only to re-lower its gear and turn back toward the runway a second or two later. Below is the script I used to make that happen, but it's basically the same as just setting a "Switch Waypoint" command in the ME. Both do the funky raise gear and turn away, then lower gear and turn back thing. Thanks again for the suggestions. In the end I just accepted that RTB is a black hole. Once AI goes in, it doesn't come out local Red3 = Unit.getByName('Red CAS 3'):isActive() local Group3contrl = Group.getByName('Red CAS 3'):getController() if Red3 == true then local _destination = {} _destination.fromWaypointIndex = 4 _destination.goToWaypointIndex = 5 local _return = {id = 'SwitchWaypoint', params = _destination} Controller.setCommand(Group3contrl,_return) end

The scenario: Single player CA mission with lots of ground units. CAS aircraft for red and blue have had their 'CAS' waypoint actions deleted and replaced with a series of scripts and triggers that assign them bombing and missile attacks from an orbit waypoint. Everything works great except for one frustrating 'bug': Occasionally (maybe 15-20% of the time) after the CAS aircraft has been assigned a target and initiated its attack run, a ground unit will kill the CAS aircraft's intended target vehicle before the aircraft can fire its own weapon. When that happens the CAS AI immediately breaks off (which is fine) and executes an RTB (which is not fine). I want it to go back to its que and pick up another attack command. While transiting back to its airbase it will always cross through the zone that assigns a new attack, but it ignores that and continues to RTB. I've read elsewhere in this forum that once AI assigns itself "RTB" it becomes a lost cause...I've tried everything from 'Go to waypoint' triggers to using scripts with popTask(), resetTask(), setTask() and pushTask() to force it out of RTB and back into the fight. Nothing works. PopTask, setTask, and resetTask tend to throw "Mission Scripting" errors (or crash the game to desktop) while triggering 'Go To Waypoint' through the ME just makes the aircraft wobble a bit, turn toward the correct waypoint, then immediately turn back to its RTB flightpath. I can kill the plane thru scripts and force the next CAS aircraft to spawn in, but that costs valuable mission time and more often than not the CAS aircraft I'd be killing is still at 100% health and chock full o' perfectly good weapons for blowing things up. Hoping someone out there has a way to work around this...Or am I just S.O.L?

That totally worked. Same script but just change the task to engageUnit and the AI queues up 4 missile shots, then peels off and heads to its next waypoint. Perfect. In this mission I need the AI plane to save at least one Mav for later events, that's why the # of shots it was taking with 'attackGroup' mattered. Interestingly enuf, this method is actually a little more useful given that attackUnit or attackGroup won't allow you to select an oddball # of shots. Eg: I can pick '1', '2', '4', 'All', etc. but not say, '3' or '5'...Like I said, I only need to save one Mav so if I can kill 5 tanks on that first pass instead of 4, all the better. Thank you, sir. Very helpful stuff, as always

Yeah, I know just enough about coding to break every best practice there is I've dabbled with the weapon codes before and while 1835008 does work, the AI seems to prefer the APKWS missiles that are on board over the Mavs. I can't seem to make 'Fire and forget' work but 131072 does get the AI to use Mavs before the APKWS, so I stuck with that. Thanks for the heads up on calling the object from the unit name string, I nixed that part of the code and made the other tweaks you suggested. Also switched up how I looped through the first 4 vehicles but the behavior of the AI remains the same...It 'sees' that the first vehicle is a valid target and shoots at it, but then peels off and doesn't iterate shots at vehicles 2, 3, and 4. I dunno, seems like I must be using the loop wrong, or maybe the game engine just isn't capable of queuing up 4 'attackUnit' tasks in a single script execution(?) local targetTable = (Group.getByName('Red Armor 1'):getUnits()) for uObj = 1, 4, 1 do if (targetTable[uObj] ~= nil) then local Target1 = {} Target1.unitId = (Group.getByName('Red Armor 1'):getUnits()[uObj]):getID() Target1.weaponType = 131072 Target1.expend = "One" Target1.attackQtyLimit = true Target1.attackQty = 1 Target1.altitudeEnabled = true Target1.altitude = 3000 local fire = {id = 'AttackUnit', params = Target1} Group.getByName('Blue CAS 1'):getController():pushTask(fire) end end

Having lots of problems getting AI CAS aircraft to honor the "expend" parameter (# of rounds to shoot) when I set up an Attack Group trigger in the ME...If I give an A10 6 Mavs and set up an "attack group" trigger telling the aircraft to fire 4 Mavs at an armored column, it always fires all 6 of them. The same happens when I use an "attackGroup" lua script Did some reading and it seems like 'attack group' might be bugged in that way. The 'expend' parameter does seem to work with an 'attack Unit' trigger or script, so I tried a work around. The idea was to use a for/do loop to iterate through the first 4 units in the armored column and shoot a single Mav at each...It doesn't work and I'm pretty sure it's just because I suck at lua and have my loop set up wrong (kind of a beginner here) Using the below code, AI picks the first vehicle, fires a single Mav at it, then peels away and ends the attack. I THINK I understand why it's doing that given the syntax I'm using, but I can't figure out how to tweak it so that AI iterates through the first 4 vehicles and fires a single missile at each before disengaging. I'm pretty sure a number of 'attack unit' triggers and flags in the ME would work but that would lead to problems of its own so I'm hoping there's a way I can do it with lua. Do I just need to fix my code, or is it not possible to do this with the kind of loop I'm trying to use? Thank you in advance local targetTable = (Group.getByName('Red Armor 1'):getUnits()) for i, Unit in pairs(targetTable) do if i <= 4 then local Name = (Unit.getName(Unit)) local Target1 = {} Target1.unitId = Unit.getByName(Name):getID() Target1.weaponType = 131072 Target1.expend = "One" Target1.attackQtyLimit = true Target1.attackQty = 1 Target1.altitudeEnabled = true Target1.altitude = 3000 local fire = {id = 'AttackUnit', params = Target1} Group.getByName('Blue CAS 1'):getController():pushTask(fire) end end

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.

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.

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.

...once again, Grimes to the rescue. You have no idea how many times it's been one of your posts that provided an 'ah ha' moment for me Thank you so much, sir. Knew it would come down to me not understanding how to use it.

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

The function "timer.getTime" might work. It returns elapsed game time in seconds. There's 86400 seconds in a 24 hr day. Not as ideal as 24hr time but you can still count 'x' hours worth of seconds and run whatever scripts or triggers you want off that. https://wiki.hoggitworld.com/view/DCS_func_getTime edit: Simpler approach: You can set the mission start time, then just do the math for elapsed time in seconds and add a "Time More" condition to a script when you want the background to change.

I'm making a CA mission w/ both AI and player CAS aircraft. The below script is written to force AI aircraft to attack from 090 (heading 270, coming in from the east) at 6000 ft (1800 m) and drop a single CBU on the lead vehicle of a column heading 090 (coming from the west). This should make for a head-on encounter. The script works, but only partially. The AI aircraft follow every part of the attack profile *except* for the "Target.direction = 090" part. It doesn't matter what original orientation I put the aircraft in relative to the armor column, it always changes its flight path to make its attack come in from an azimuth of 120 instead of 090, even if I start the plane on a course of 270 (due west). A similar effect happens no matter what compass heading I enter, but it's most obvious when I use the cardinal directions (000, 090, 180, 270) I tried tweaking the heading to account for the apparent 30 degree deviation but all that does is force the aircraft to take even weirder approach angles. Basically, nothing so far has made the aircraft attack the column from true 090. To complicate things, if you set up the attack using the "Attack Group" or "Attack Unit" waypoint actions in the ME it obeys the azimuth command every time. Unfortunately I can't use this method because I need the AI to be able to dynamically select the lead vehicle in the column, which could change based on mission conditions (eg: vehicles start dying ) Everything I've read says "Target.direction" should specify the direction the attack comes from, its azimuth, but when used in game via a "Do Script" trigger, it deviates every time for me. So, do any of you know if there's some aspect of this parameter I'm using wrong? A bug or something maybe? ...I'm baffled at this point, been testing it different ways for days now but keep getting the same result. Interestingly, if you let the core "CAS" AI just do its thing, the aircraft will eventually decide to drop a CBU on the column from an approach of 090, it misses completely, but hey, at least it's trying local Target = {} Target.unitId = Group.getByName('Red Armor Test'):getUnits()[1]:getID() Target.weaponType = 256 Target.expend = "One" Target.directionEnabled = true Target.direction = 090 Target.attackQtyLimit = true Target.attackQty = 1 Target.altitudeEnabled = true Target.altitude = 1828 local fire = {id = 'AttackUnit', params = Target} Group.getByName('Blue CAS Test'):getController():pushTask(fire)

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.

So... It looks like I couldn't pass the target point to the FireAtPoint task because I wasn't using "getPoint" correctly. Newb oversight, but there ya go... "getPoint" returns Vec3 coordinates, but artillery needs Vec2 coordinates, so "getPoint" by itself will not fetch a valid FireAtPoint target point. Vec3 points are defined by "x, y, z", Vec2 are defined by "x, y", so you have convert the Vec3 to Vec2 before passing it to the FireAtPoint task. To convert a Vec3 point to a Vec2 point, just take the Vec3 "z" coordinate and use it for your Vec2 "y" coordinate. After that, everything works like you'd expect. Simple in hindsight, don't know why it was stumping me like that Anyway, this script will dynamically assign a FireAtPoint task to the coordinates of any ground target you want based on whatever conditions you apply to it in the "getBy" function(s) and/or the ME. local Target = {} Target.x = Unit.getByName('Target1'):getPoint().x Target.y = Unit.getByName('Target1'):getPoint().z target.radius = 10 Target.expendQty = 20 local fire = {id = 'FireAtPoint', params = Target} Group.getByName('Arty2'):getController():pushTask(fire)