Grimes

Removing the role is mostly for instances where there are targets outside the area you want the AI to be attacking at. For example wanting a SEAD flight to target specific sams but they see an EWR 200 miles away first and go for that. I haven't messed with the escort task much lately to be honest. It kinda fits the role of cool looking aircraft flying in formation, but tends to slightly compromise the AI's ability to execute their actual mission. Just giving them their own flight plan and to be slightly ahead of whoever they are meant to escort works best. Weapons wise the Mk-82 snakeeye (or air) isn't great for that tasking. AI will always do a fast and low level bombing, and will usually miss. Use normal Mk-82s and they will typically dive bomb the targets or at least be more accurate level bombing. For what it is worth you won't be destroying that command bunker with Mk-82s. It normally takes about a dozen Mk-84s to destroy it.

Every script that would use flags would ultimately also use trigger.misc.getUserFlag. They might have something that would check values or store which flags were used in a lookup table, but there is no way for them to get around using the functions to set and get a flag. IMO there are only two reasons to use flags with scripting. 1. Setting flag via script and using the same flag with a defined trigger or waypoint action. Its more of a hybrid where you use scripting to do what the editor can't easily do, but still use flags to do some basic stuff. 2. Setting flag via script and only checking that flag via script. The main advantage is that you could name the flag rather than using a number value. For instance: trigger.action.setUserFlag("easyMission", true). Eliminates the need to remember which flag does what. But frankly you could also just define global or local values within a self contained script to accomplish the same thing.

Did some tests and quad zones seem to be broken while circular zones are fine. There is a possibility that your expected outcome isn't matching the functionality. The zones are always centered on the object you are linking them to. It isn't offset relative to where you put the zone at. So your quad zone would be more like the screenshot. Also orientation likely isn't factored in either. For circular zones it obviously doesn't matter, but for a shape it would.

The sun and moon cycles should adjust accordingly as time marches on.

You can't force it. The one hour period is hard-coded at the moment.

It keeps going.

I just wrote the example in a way that would execute immediately. Once>Time Less than 5 basically executes right after you unpause the mission. The conditions don't really matter as long as you set the flag to a random value when you want things to spawn.

https://wiki.hoggitworld.com/view/DCS_editor_Randomization#Single_Choice_from_List Single choice from list or Random Integer List are the best choices. Main advantage of single choice from list is that you can set the flag to false again and it will make another choice from what remains. Downside is that it isn't instant and depending on the random value you set can take several seconds to over a minute to activate. Likewise random integer list is instant, but activating another choice later can require multiple "dice rolls" as each choice gets eliminated the probability of it randomly getting an unused value decreases.

Two likely possibilities. 1. The fire at point task isn't finished. Easiest way would be to set the rounds expended to 1. You could also set a stop condition to accomplish the same thing. 2. It is rearming. If a truck is nearby or the SCUD is near an airbase/farp it can decide to re-arm on its own and will stay stationary until that process is complete. If you didn't stop the task it'll just launch another missile and do that endlessly.

Add waypoints or an orbit task to their route so that they have time to detect you. Also a triggered action has to be triggered for it to be active, you can just assign the task as part of their advanced waypoint actions. Alternatively you can use "attack unit" and when assigned they will B-line for you. This page might help: https://wiki.hoggitworld.com/view/DCS_editor_AITasking#Perform_Task_vs_Enroute_Task

Fixed some issues with stat recording and the stat display. https://github.com/mrSkortch/DCS-SLmod/commit/ed9c2cc06a99429fc2675d857c248892730bce22 If the command "-full stats me" doesn't work please let me know.

Installing it on the server should have done the trick. It actually doesn't even need the texture files, it just requires the description.lua in the correct location for it to work. What is happening is if you have a mission file with X custom livery set for an AI, the server loads the mission, looks for X, can't find it, and then chooses a default livery for that aircraft. Same thing happens locally if you a miz looking for liveries you don't have.

Nothing stops you from spawning the same objects in the same place as dead objects. Best to confirm that the respawn function is actually being called. Add a message in the block before and after. You can do that either with env.info('whatever') and check your DCS.log file or trigger.action.outText('before respawn', 20) so that it appears as a text message on screen.

Donno if that is a typo because you have to convert LO to LL and then LL to MGRS. There is no direct LO to MGRS. In fact this is what the code looks like when mist does it: mist.tostringMGRS(coord.LLtoMGRS(coord.LOtoLL(avgPos)), acc) Probably something that could be a bit clearer on the wiki, but you are kinda going about it backwards. You are averaging the position of a group with 4 units making up a grid square the target is in. You could just pass different values for the acc entry with the target coords to get the same result. Its documented in the tostringMGRS page but none of the other MGRS related pages. mist.tostringMGRS(table, 0) returns 38T AB mist.tostringMGRS(table, 3) returns 38T AB 123 123 mist.tostringMGRS(table, 5) returns 38T AB 12345 12345

ED changed it sometime in 2020 and I'm not sure when the changes were merged. Possibly with the first 2.7 patch.

The radar no longer rotates. If you need to cover more area you need to add more radars and orient them as needed.

Looks like trigger.action.outTextForCoalition isn't working correctly. The "clearview" setting is ignored, which is what mist uses to overwrite previous messages. That whole section of code in mist was made before messages in DCS could stack like that, so it works a bit like a monitor where it has a refresh rate and combines messages as they get added so nothing is erased. Also a royal PITA that you can't send messages that only CA players can see. If you jump into a group slot it should be ok. Fixing it for CA would take some work but is doable.

Wrecks and fires may have unique object ids within the sim but there is no way to query it.

Some typos on my part. Pro-tip always test code used in advice you give to someone even if you think it'll work. Edited code from my earlier post and added some debug messages + reduced the time so it is easier to check.

Yeah it was returning nothing for a few patches so I never documented it. Since it is working now I add a page for it.

There is a lot of trial and error involved in trying to get the AI to do what you want. Sometimes it involves understanding the tasks assigned to them and other times its just changing one variable at a time to see if something different happens. There are plenty of instances where something as simple as waypoint placement when assigning a task can result in what appears to be bugged behavior. Arguably some of that does occur with default settings and tasks, but at the same time they are default because its the easiest way to get basic expected behavior without having to change anything. Your example of AI ignoring tasks and attacking an SA-2 sounds like you kept the default "SEAD" task enabled. This task, along with other similar ones like CAP, CAS, Fighter Sweep, and anti-ship, all allow the AI to attack certain targets at anytime during their flight. So if you place a CAP flight, give them a CAP task, and then tell em to orbit they will either: 1. If no targets are detected, orbit, and freely break from the orbit to attack any aircraft that pop up 2. Detect targets before reaching the orbit, and decide to attack targets, if they live and no other targets exist, they can return to their orbit to wait to attack anything else that becomes detected. The fun part is how that might change as you add stuff into a mission. Adding an AWACS to the side of the CAP flight and all a sudden they are able to detect targets much further away. Remove that AWACS and the targets themselves play a role in detection. Mig-15: CAP flight will have to detect em visually or if Mig-15 comes within radar range Mig-21: CAP flight would react to RWR of the Mig-21, but at relatively short range Mig-29: Again RWR would cause CAP to be aware, but at a further distance than the Mig-21 Mig-31: Again RWR, but at much longer distance. This applies to SEAD and to the SA-2 in the sense that SAM behavior in game is rudimentary at best, they turn their radar on if any aircraft gets within the detection range. Therefor if you have a SAM with a large detection range and a flight with the default SEAD task, chances are that radar will turn itself on for any nearby friendly, and that SEAD flight will detect it on their RWR. In general if AI are attacking stuff before you want them to, check to see if there is a corresponding "enroute task" like CAP, CAS, SEAD, FighterSweep, and anti-ship. If there is, delete it, and replace with any of the "Search and Engage" tasks. Big difference between these and "Attack Group/Unit" is that the attack tasks forces AI to know about it, whereas search then engage requires AI to detect the target via any of their onboard sensors. Search then Engage: This is actually the task that CAP, SEAD, etc are actually using. Big difference is you can set the target attributes and limit valid targets to be within X distance of the entire flight plan S&E InZone: Limits the targets to be in a specific area. Best used with multiple zones. S&E Group: Limits the groups the AI is allowed to attack S&E Unit: Limits the units. Best for SEAD or Anti-ship because you have control over how the AI attacks. This is important because AI don't "waste" weapons, they fire exactly how many missiles it'd take to kill a given target. They aren't really calculating what happens if they miss or the missile gets shot down by the ship or sam. Instead of having a 4 ship of F-18s armed with 16 HARMs fire 3 missiles at an SA-10 (1 at each radar), you can tell em to fire all 16 and one might actually get through. ROE plays a role in all of this because you can use it to prevent the AI from attacking stuff before you want them to. It is one of many ways to do it. Another is to not assign the tasks before you want them to attack. I mentioned it because with Weapons Free the AI is allowed to go "off mission". They might more willing to use their onboard a2a missiles on a target or use A2G weapons before you want them to. I've attached a mission to show this. Just change the ROE of the flight on their initial WP. The AI is assigned a tasks at WP1 and WP2. With only designated they ignore the group they fly over and attack when told to. With ROE of priority designated or Weapons Free the AI will attack the group along their route, then go after the EWR before being assigned the target, and then return to their flight plan. ROE_sample.miz

Yep, make a template that gets imported into the "big picture" mission.

With the ground attack task and the default ROE setting AI shouldn't try to attack stuff on their own. So it isn't something you should need to change to prevent that behavior. Nothing wrong with changing it to be safe though. GBU-31v1 and GBU-31v3 were the original bombs and should be ok in terms of behavior. They added v2 and v4 at somepoint, possibly with the intention of giving them the fire resistant coating texture that the USN/USMC variants of the bomb typically have. For whatever reason the AI don't use 31v2, 31v4, and gbu32 the same way as other JDAMs.

Edit>Save Static Template It effectively saves all of the groups placed in the mission as a miz like file. Then open the mission you want to import it into and load that static template. It doesn't import weather, triggers, or anything like that. Just the groups and their waypoints.

Yeah it appears to be a combination of the settings applied that breaks it. For the JDAM it appears that the AI don't know they can ripple GBU-31v2, GBU-31v4, and GBU-32 like they can the other JDAMs. Formation appears to play a role with when the 2nd in the flight will attack. Simply put if they are in a tight formation the wingman might feel that it doesn't have enough time to attack on that initial pass. Carpet bombing doesn't like the ROE you set for whatever reason. Its fine with the default "only designated" type but they will use one bomb a pass with priority designated and weapon free. BTW, please delete more of the units in the mission to show certain behaviors. I realize that the combination of settings was at fault here and your attempts to recreate in another mission failed, but I deleted everything but the two flights of F-18s and was still able to replicate it. Especially when needing to change a setting, check what happens, and repeat it is a bit of a waste of time watching AI taxi, take-off, orbit, and fly a long distance before seeing the test behavior.