Grimes

This setting applies to engaging airborne targets.

For the Apache FCR you should be able to use getDrawArgumentValue. https://wiki.hoggitworld.com/view/DCS_func_getDrawArgumentValue Although it might have weird results because people can have an FCR be forced onto the aircraft as part of the livery, but if it wasn't setup in the miz to have an FCR it would be non functional. Likewise it might change when the FCR gets added to the loadouts.

As long as you are using pushTask and also not pushing a new mission task to the unit it *should* return to its orbit point once all pushed tasks it has is complete. If it was setTask then that task will overwrite any other task it has and I would expect the AI to return to base if they weren't given any other tasks. If you were giving it a new mission task then I would append a waypoint with the orbit task to the original orbit points so that it is part of the route.

Link unit would be the unitId of the carrier, not the groupId. Also the groupid and unitId of the static object should be unique, which you could comment out and allow DCS to figure it out for you or I'm sure there is some function in moose that would give you an unused id for either. Might also be a good idea to wait a tick or two before spawning the statics on the spawned ship. I'd have to look through my test code to see if I had made something to verify it works on spawned ships, pretty sure I did, but it wouldn't have used moose, so I can't help on that part of it.

if var then if type(var) == "string" then -- do string things elseif type(var) == "table" then -- do table things end else -- its nil end Check for its existence and the type.

You need to check for its existence first. It is inconsistent in returning in MP, but it can return. In SP it is much more consistent.

attackType = "Dive" apparently. Added it to the wiki.

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.