Grimes

Yeah looks a little bugged. You can get expected behavior by directly passing the markId that is associated with each segment of the line. local rtn = mist.marker.drawShape("lineTest") -- Then latter you can pass the markId value associated with each shape. for i = 1, #rtn do mist.marker.remove(rtn[i].markId) end

Best guess is periodically running world.searchObjects within a set radius of the helicopter based on altitude then land.isVisible to check visibility and probably an azimuth to verify the target is "in front" of the aircraft. Add those units to a list and if it is new then "announce" to the player via some text to speech. And then some coordinate formatting and other stuff for the messages.

Could try engageUnit. https://wiki.hoggitworld.com/view/DCS_task_engageUnit It doesn't necessarily require the previous task to be completed before the AI is allowed to engage any other valid targets. As for the weapon flags, you cannot really tell AI to prioritize one weapon over another if they are both governed by the same waeponType value.

Three things. 1. It would be good practice to not use the name of any of the main object classes as a variable name. for i = 1, uObj in pairsj(targetTable) do would be better. Or even just a lower case unit. 2. You don't need to get the name, then use that string to get the unit object, so you can get the unit id. You already have the unit object. Target1.unitId = uObj:getID() would work. 3. If AI refuse to attack whenever you have a set weaponType it is good to try other weapon enumerator values. I'd try 1835008 for tactical ASM or or 262144 for fire and forget ASM. Its possible that "anti tank" missile is more in line with any of the ground launched ATGM like a TOW. I don't know anywhere in the files where it explicitly says "weapon has X weapon flag value". You just gotta try different things to figure it out.

It doesn't automatically unpack any table passed to a function. Generally its a good idea to create a wrapper function that will then manipulate the values passed and call the expected function. Basically add ctld.JTACAutoLase to the values passed in the table and create another function that then calls ctld.JTACAutoLase with the other parameters. Though you could try: local subN1 = missionCommands.addCommand('JTAC Activate', subR1, ctld.JTACAutoLase, unpack({ 'JTAC1', 1688 }))

They aren't in the same group. See its unit 1 of 1. That means you have unit 1 selected in the group, which has only 1 unit in it. Use the + icon or the > button on the right to add units to the group. + inserts a unit at whatever index you are at to the left. Which means what was unit 1 becomes unit 2. Where-as if you add the unit via > it adds the unit to the end of the group.

One of the icons on the toolbar opens a UI that you can select the code used for the syntax highlighting. Its the icon that looks like <>. local seadAsset = missionCommands.addCommand( 'SEAD' , requestAsset , request, {type = sead} ) The 3rd input for that function is the function to run. You had it as mist.respawnGroup, which can work, but not with what you sent to it. However you want it to run the request function. Which will then in turn run the mist function with the correct inputs.

There have been a few bugs that have creeped into slmod's event handler due to changes in the data present in certain events. For example some of the shot events with AI will give the target as "point" which is basically a non-object entity that the AI is targeting. At which point an error like that might occur because slmod was expecting a target to be an object like a unit or a building. In a sense it is fairly normal because I haven't gotten around to fix it. slmod will continue to function, its just stats related to that event will not occur. Each event handler runs on its own, so any given bug in one wouldn't stop the others from running too.

The server uses a bubble script to spawn units in and out based on a number of factors. You can only have so many units active at a time in a mission before performance starts to tank. The Sinai mission has about 18000 units placed in the mission editor, of which 2000 are client slots. A large portion of those units will only ever be active when the objective they are in is active, but a few thousand, mostly sam sites, can be spawned at anypoint. Occasionally there are instances where the units don't spawn when they should or despawn before they should. I'm always on the lookout for such event, but it is often difficult to reproduce due to it not consistently occurring combined with the complexity of the script. All things considered your JSOWs should have caused the bubble units in their area to spawn back in.

The log file is not helpful for this sort of thing. Post the miz or a track file so someone could see how its setup and might figure out the problem.

Generally whenever you see multiple units with "SAM [type of system] Unit Type" then you will need 1 of each of those objects for it to actually shoot. There are additional rules and caveats but that is the bare minimum. Make sure the Tor, Tunguska, and Osa aren't in the same group as the main sam system. Caveats Some sams have multiple types of search radars that will work with it. Its fine to have all of them if you want. SA-10 requires flat terrain to deploy. If the ground isn't flat enough then the search radar, tracking radar, or launchers will not deploy and function as expected. SA-11 launcher can shoot on its own if it visually detects a target. Patriot STR cannot rotate to look in a given direction. The direction the unit is facing is about a 90 degree arc that it can see. Patriot launchers also have a limited FOV, basically can't shoot behind them.

mist.groupIsDead("Aerial-21") == true as the condition instead of if not Group.getByName() Could also try adding logging to see where it gets to. For example local function doRequestFunction(vars) trigger.action.outText(mist.utils.tableShow(vars), 10) if vars.type == "SEAD" then if not Group.getByName('Aerial-21') then trigger.action.outText("RESPWN Aeiral 21", 10) mist.respawnGroup('Aerial-21', true) end -- you forgot to close is by the way. if not Group.getByName('Aerial-22') then mist.respawnGroup('Aerial-22', true) end Could also use a program like notepad++ to write the code in. Use the lua visualizer and it can help spot bugs like failing to close if statements.

https://wiki.hoggitworld.com/view/DCS_func_addStaticObject Basically need coordinates, type of object, and a unique name. The most complicated it gets is just mathematics to manipulate x, y, and heading values as desired. An easy example would be to spawn something on a trigger zone named "spawnHere" local point = trigger.misc.getZone('spawnHere').point local staticObj = { ["heading"] = math.rad(math.random(360)), ["type"] = "Cafe", ["name"] = "dynBuilding", ["y"] = point.z, ["x"] = point.x, } coalition.addStaticObject(country.id.USA, staticObj)

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. 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.

https://wiki.hoggitworld.com/view/DCS_command_setFrequency local freq = { id = "SetFrequency", params = { power = 10, modulation = 0, frequency = 131000000, } } Group.getByName("someGroup"):getController():setCommand(freq)

Not with sams. The AI must have a target for it lock to fire off a missile.

There is no function to get the "live" livery_id a unit is currently using. Like cfrag stated you can only access what livery the unit started with.

Those functions are native DCS scripting functions and have nothing to do with mist. I don't actually have any functions built into mist to create menu items for people. To answer your question the doRequestFunction has to be a function that is declared somewhere. Otherwise when you select the command it won't know what the execute. local function doRequestFunction(vars) if vars.type == "SEAD" then elseif vars.type == "CAS" then elseif vars.type == "CAP" then end end local requestM = missionCommands.addSubMenu('Request Asset') local rSead = missionCommands.addCommand('SEAD', requestM, doRequestFunction, {type = "SEAD"}) local rCAS = missionCommands.addCommand('CAS', requestM, doRequestFunction, {type = "CAS"}) local rCAP= missionCommands.addCommand('CAP', requestM, doRequestFunction, {type = "CAP"}) Also that sample on the wiki had some typos with mixing " and ' to define strings which would have also caused an error.

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.

Azimuth is in radians, not degrees.

Anything set to take-off from runway will be moved to take-off from parking area hot when the mission runs in multiplayer. It is a feature of the game you have no control over. Best to airspawn the group or place it take-off from parking hot to begin with so that there aren't any potential issues with it choosing a bad spawn point.

Yeah, you are right. I have a tendency to think one thing and type another. Sometimes I notice it and correct it. Evidently not that time.

Gonna have to add some details. If you know the runtime object id then it is accessible via the scripting engine. So yeah, you can right click to populate a trigger zone that represents the object, however the object id can still be useful. Here is a basic function that takes the object Id displayed in the trigger zone and creates a table using that id value. Which then use an Object function on and lo and behold it returns a value. This is the result. So yes, if you know an object id you can just make a table in the format of {id_ = number} and scripting functions will work with it. Can't call functions like {id_ = whatever}:getTypeName() because its not an object in the traditional sense. The downside, and its a biggie, is that when the map updates EVERY single object id will be changed to something different. This is where the trigger zone can come in handy because you know object type exists at a specific point. You can use world.searchObjects to get the current runtime id of the object by checking known coordinates and typenames. The upside is that the id values don't update all that often, but they can update, which will throw a spanner in the works.

Yup its very much possible. https://wiki.hoggitworld.com/view/DCS_event_mark_change to get the point and if you want to parse the text for the command. Pass the coordinate to a function that assigns a route.

I don't really keep the pdf up to date anymore. Best to check the hoggit wiki and the pages on mist for better examples. https://wiki.hoggitworld.com/view/MIST_group_alive_less It is simply easier to update the wiki with new info or fixes than the pdf. This function doesn't support multiple group names, it will only accept one. You would have to call it for each group that is valid. Which might look something like this: spawnGroups = {} -- table containing units for respawning (and other things) spawnGroups[1] = "Halo 1" spawnGroups[2] = "RED AWACS" spawnGroups[3] = "HOS SU-27" spawnGroups[4] = "SAM NORTH" spawnGroups[5] = "SAM SOUTH" spawnGroups[6] = "CONVOY 1" spawnGroups[7] = "Train 1" -- Populate groupNames with values from spawnGroups[4], spawnGroups[5], and spawnGroups[6] for a = 4, 5 do -- you had 6 here, it would have included the group at index 6 mist.flagFunc.group_alive_less_than( { groupName = spawnGroups[a], flag = tostring(a), percent = 20, toggle = true, }) end Alternatively making your own function isn't that bad. local checkGroups = {"SAM NORTH", "SAM SOUTH"} local function checkAndRespawn(gName) timer.scheduleFunction(checkAndRespawn, gName, timer.getTime() + 60) local gp = Group.getByName(gName) if gp then local ratio = gp:getSize()/gp:getInitialSize() if ratio < 0.2 then mist.respawnGroup(gName, true) end end end for i = 1, #checkGroups do checkAndRespawn(checkGroups[i]) end