Grimes

They are all of the markup functions in trigger.action. https://wiki.hoggitworld.com/view/DCS_func_markupToAll

getGroupData with a route flag shortens the returned route table and cuts out the points entry. This ought to work. groupData.route[1].speed Also a speed of 436 is about 850 knots because that value is in meters per second. mist.dynAdd is overloaded to convert it to route.points needed by the game if the route table entry passed lacks a points.

Was out of town for the week. From the logs it looks like slmod is loading normally. The error related to world event hooks and specifically the addToDB function is caused by a DCS bug introduced in the last patch. Basically any static object that gets added via script won't be in the slmod database for tracking kills because DCS is returning the name incorrectly.

getZone only returns circular zones still, you have to parse the the mission table. You can save it and reference the zone name to get the vertices. local zones = {} if env.mission.triggers and env.mission.triggers.zones then for zone_ind, zone_data in pairs(env.mission.triggers.zones) do zones[zone_data.name] = zone_data end end

That is quite astute because that is more or less the default behavior. To get maximum saturation it is best to micromanage the AI. From what you write that appears to be what you are doing with those parameters it should work relatively well. I'm gonna guess that the default SEAD task is still assigned. If it is then delete it. If I'm right about that then the problem is that the AI detect a target then leave their route to attack said target. This is a problem because by leaving the route they don't actually pass the waypoint that assigns the attack group tasking. The default behavior for each of the enroute types (CAS, SEAD, Anitship, etc) has an internal calculation for "can this weapon kill the target" to decide how many to shoot at a given target. They don't account for the weapon failing due to be shot down. Thus for SEAD it results in firing 1 missile at 1 radar at a time, hence the need to micromanage. More groups is one solution to it because this rule only applies within a given group. Assuming you use attack group, attack quantity = 1, group attack = true, and define a weapon release quantity then you should get them all to engage with what you tell them to. I will add that the attack group/unit tasks have a, lets call it a vulnerability, for SEAD tasking where the AI CANNOT engage a sam in a pre-brief type mode. In order to use an anti radiation missile on a target the AI must be actively detecting it. If the radar is off or obscured by terrain then the AI cannot engage with ARMs. This doesn't apply if you tell it to shoot a JSOW or really any non ARM at it. This is one of the bigger advantages of "search then engage" tasks because it allows the AI to attack that target when they detect it. Additionally assigning a attack/engage unit task is beneficial compared to the "group" counterparts because that allows you to prioritize the target unit. In a quick and dumb test with the SA-10 missile intercept disabled of 16 HARMs shot by a flight, 12 went to one search radar and 4 to the other. Specifying a unit allows you to equalize the odds of both getting hit. If removing the default SEAD task doesn't help then post the mission file and I'm sure the problem can be solved.

It is map rules more than it is AI.

What map was this on? Could you post the mission or a screenshot of it doing the following? I ask because there are two possibilities. The first is that the lines drawn in the editor don't match the route precisely. This isn't a problem, those lines are approximations to the road/rails. What matters is that in general the lines follow the path. You should get an idea of what that looks like with my attached image. Which leads into... The second possibility effects trains more than it does ground vehicles, but can still apply. Trains are implemented in an extremely rudimentary way currently and have been since they were first introduced. Additionally a lot of maps have sections where a train either can't navigate or it is a single rail allowing travel in just one direction. Having a road allow travel in one direction can effect ground vehicles, but they have many more route options and can go off road so it is less of a problem. My screenshot below shows an example of travel in one direction on the Normandy map. Trains also can't do complicated routes where it might require the train to stop and reverse. This gets it classed as an invalid route. If a train doesn't have a valid route it simply will not spawn.

The editor isn't checking for the presence of a ship deck when placing objects, it only checks the terrain type. In this instance it is land or not land. I don't recall it working in the past, but tested just now. At present you can put any amphibious unit on the deck, but any movement will likely cause issues. Interestingly it does seem to impart some "attachment" to the object because units sitting on the deck or glitched due to said movement behave the same as a static object linked to the ship. With appropriate translations of position relative to the ship's movements. I suspect at worst it is a happy accident from work on the Super Carrier or at best WIP/partially implemented functionality for the future. Also didn't test in MP and it is likely objects may still fall through the ship. At least on Grayflag someone managed to dropoff a crate on a ship and it fell into the sea which existed for a few days before being cleaned up. https://imgur.com/iAZU9Oa

Two take-aways. That is actually kind of close. Why do I get the sense it might have been trained on something I wrote... -- Create empty tables to store the EWR and threat units local ewr_units = {} local threat_units = {} -- Loop through all units in the mission and store the EWR and threat units for uName, unit in pairs(mist.DBs.unitsByName) do if string.find(uName, "^EWR") then -- first problem that it was checking unit.name, which is nil. But the first value from the in pairs is the unitname, so just use that. table.insert(ewr_units, unit.groupName) -- it was inserting the whole table entry of the mist DB. I changed it to the group name since you cant use the unit controller for ground units. end if string.find(uName, "^Threat") then table.insert(threat_units, unit.unitName) --- this is the unit names though. end end -- Output the contents of the ewr_units and threat_units tables local ewr_units_str = "EWR units: " .. table.concat(ewr_units, ", ") local threat_units_str = "Threat units: " .. table.concat(threat_units, ", ") trigger.action.outText(ewr_units_str .. "\n" .. threat_units_str, 10) -- Define function to check for detections local function checkDetections() for j, radar in pairs(ewr_units) do -- I swapped this because its more likely that you will have fewer radars to be checked. local radarGP = Group.getByName(radar) -- it was passing the whole mist DB table entry for the radar.. which can't be directly used in the controller. if radarGP then -- it also assumes everything is accessible and not killed. Which is why I added a bunch of if statements. local rCon = radarGP:getController() -- gotta get the controller to pass to isTargetDetected for i, plane in pairs(threat_units) do local tUnit = Unit.getByName(plane) -- get the plane because again it was a mist.DBs entry. if tUnit then -- unit must be accessible and alive. if Controller.isTargetDetected(rCon, tUnit, Conroller.Detection.RADAR) == true then -- the radar call was wrong because RADAR by itself is not declared anywhere trigger.action.setUserFlag("detected", true) end end end end end -- Schedule the function to run again in 1 second timer.scheduleFunction(checkDetections, {}, timer.getTime() + 1) end -- Schedule the initial function call in 1 second timer.scheduleFunction(checkDetections, {}, timer.getTime() + 1) Donno what happened with some of the tabs. It had a lot of the right ideas of how to do it but the wrong specifics. There are a few optimizations that can be made like saving the group controller and unit objects, then checking if they are still alive rather than constantly re-calling Group.getByName and Unit.getByName each time the function gets called. Especially if you have multiple EWRs it is going to get the same unit X times each check when it already has them. But I kept it roughly in the same format for the sake of comparison.

That cannot be done. You can only force aircraft to attack friendly units directly. Only team-killing by AI sams will be the accidental variety with the occasional IR system and more likely with a NASAMS if they shoot into a furbal.

Reported.

The files within a .miz are just lua tables. As a result you can edit the files externally however you wish. Its how the user made mission generators function and tools like the upcoming DCS Web Editor work. I don't know if anyone has made a tool to modify multiple missions as a batch of sorts. Usually its something as basic as injecting different weather into the next MP mission that gets loaded by a server.

Unfortunately no, this does not exist currently.

The full DCS.log of the server starting would be helpful. Those first two lines are normal these days. ED changed something in the server loading process that slmod uses which causes slmod to try to load sooner than it used to. Basically when it tries to do it again it is successful. After that though there should be a lot more slmod entries before the create events log.

With scripting you can assign a new task to individual aircraft in a flight, for instance to make that unit RTB. However whenever you tell the flight lead to do something it trickles down to any other flight member. As a result it isn't super great if you want them all to do something different. It is best used for something like sending a flight to attack an area and micromanaging each unit to attack specific targets. I think it would probably require re-assigning the task to each flight member whenever flight lead was told to RTB. As for difficulty for someone of a skill you describe, ehhhhhhhh not at all easy.

Reported.

It is possible but there are a number of hurdles that you have to deal with. Easiest way would be for each aircraft to be in its own group. When you make their route you set a stop condition for every single task they have to be the same thing, like a flag is true. You also need to make a trigger for each unit that checks if it has been hit. The hit event should still occur if the group is immortal. When it triggers the action needs to be to switch waypoint, set ROE, and whatever else. With scripting it would be a bit easier because you could re-use a task that gets assigned and just add the units to a list that forces them to RTB on hit events.

A track or mission file would be beneficial here to help debug any possible causes.

WP1 of the route is missing helipadId which is the unit Id of the unit it is spawning on. Applies to aircraft spawning on ships or static objects. ["helipadId"] = 1, Would have to double check if it matters if it is a number or a string value. At least as saved in the editor both it and linkUnit are numbers not strings.

I've had it crash like that in the past but I don't remember the precise reasons or if I've gotten it to do it on addGroup. Usually some expected value was really wrong. Best to output the table to DCS.log directly before calling coalition.addGroup. If it crashes then you can copy that table and use it in a fresh mission to see if it crashes there. Might even look at it and realize the mistake that was made.

We have getCallsign https://wiki.hoggitworld.com/view/DCS_func_getCallsign Granted it returns a string and not anything with the enum values.

Correct they haven't added a scripting function for it yet. There are a few others like that unfortunately. As for how to activate it via script the only way to do it is to have a trigger and make the condition for it to become true. Easiest way is with flag is true and you simply set the flag state via script when you need it to be called.

Correct it is a static snapshot of the mission file that was loaded. Same for env.warehouse and env.options.

Yeah so look at the example of a mission task. https://wiki.hoggitworld.com/view/DCS_task_mission Then look at the route entry for an aircraft group https://wiki.hoggitworld.com/view/DCS_exam_group_plane If you wrote a mission task that you wanted to have an AI group start with, then all you'd need to do is.... local mission = {someMissionTask} local newGroup = {someGroupTable} newGroup.route = mission.params.route coalition.addGroup(1, 1, newGroup) Same thing applies to individual tasks, but is a bit more convoluted when added as part of a mission. ["task"] = { ["id"] = "ComboTask", ["params"] = { ["tasks"] = { [1] = { ["enabled"] = true, ["auto"] = true, ["id"] = "WrappedAction", ["number"] = 1, ["params"] = { ["action"] = { ["id"] = "EPLRS", ["params"] = { ["value"] = true, ["groupId"] = 1, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [1] }, -- end of ["tasks"] }, -- end of ["params"] }, -- end of ["task"] Whereas if you decided to set a command anytime after it spawns then it is a simple call that isn't buried in the task.params.tasks[index].params.action table of a given mission waypoint. { id = 'EPLRS', params = { value = boolean, groupId = number, } }

You can re-use callsigns no problem. Its just a issue if they are both talking and knowing which one is which is actually important. I don't recall if the game picks a standard callsign if spawned without one. It is easy enough to test. No because it would be more efficient to use coalition.getGroups by limiting it to aircraft and helicopters. Could also iterate env.mission.coalition and figure out which units have callsigns set in the editor.