Grimes

I don't know if there is a limit, but I know its not 15 because I just tested it the way mist does it with 23 points and it was fine. The trick is to convert it into a string that you execute. This is what mist does. with fCal being a table where all of the entries get inserted into a table in the order that they need to be. local s = "trigger.action.markupToAll(" for i = 1, #fCal do --log:warn(fCal[i]) if type(fCal[i]) == 'table' or type(fCal[i]) == 'boolean' then s = s .. mist.utils.oneLineSerialize(fCal[i]) else s = s .. fCal[i] end if i < #fCal then s = s .. ',' end end s = s .. ')' local f, err = loadstring(s) if f then return true, f() else return false, err end Really wish they made a function for this that just accepts a table of points or a table of every parameters. Having a function with over 150 input variables seems non optimal.

I often see comments about the scripting wiki missing information or wishing it was "moar betterer" without giving specifics. Use this thread to request which pages you want to see improved or created. Please limit it to scripting engine and mission making topics. https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation

Reported.

AI generally don't like being spawned and then immediately being given a new task. Best to have at least some delay built in. Since you are spawning the group in the same motion you can easily just change the route it starts with. local cityIntel = trigger.misc.getZone(city); local ng = mist.getGroupTable('1º Defense Squadron') ng.lateActivation = nil -- group is set to late activate, remove the value so it doesn't spawn late activated ng.route.points[2].x = cityIntel.point.x --- rroute is part of groupTable, but might want to verify that waypoint exists. ng.route.points[2].y = cityIntel.point.z mist.dynAdd(ng) -- spawns the group

Spawn the helo however you want and either embed or push a ground escort task to that group. Probably best to give it a route to go somewhere near the group it needs to escort and then be given the task. https://wiki.hoggitworld.com/view/DCS_task_groundEscort

The table passed to mist.dynAdd does not have a groupName or name value. Since that value is required to spawn a group mist will generate a name in that format. The unit's correctly have a name, thus it uses the passed value. As for getting the route, that function is setup to only work on groups from the mission editor. Mist doesn't save any route info and there is no scripting function to get a group's active route. What you can do is save it yourself to a table if you want to access it later. myRoutes = {} -- declare to access it later. --- When you spawn the group do something like this. local newGroup = mist.dynAdd(vars) myRoutes[newGroup.name] = EscortRoute

Tracking shells is doable, but somewhat annoying. Here is a very quick I threw together. Its not at all optimized and has some flaws with logic. For instance it only starts the check once an aircraft stops shooting and it can schedule it to check if there are multiple stop shooting events. Also it isn't checking the existing table for if it is already tracking a given weapon. Again just something super basic that was cobbled together from a few other scripts sitting around. To see it in action check that imgur link. https://i.imgur.com/JMctEkt.mp4 local mId = 0 local volS = { id = world.VolumeType.SPHERE, params = { radius = 5000 }, } local weps = {} local ifFound = function(foundItem, val) table.insert(weps, {obj = foundItem}) return true end local function trackWeapons() if #weps > 0 then timer.scheduleFunction(trackWeapons, {}, timer.getTime() + .25) end for id, wpn in pairs(weps) do if wpn.obj:isExist() == true then wpn.pos = wpn.obj:getPosition().p wpn.dir = wpn.obj:getPosition().x wpn.ip = land.getIP(wpn.pos, wpn.dir, 200) else local ip = wpn.ip if wpn.pos and not ip then ip = wpn.pos end mId = mId + 1 trigger.action.markToAll(mId, "Impact", ip) table.remove(weps, id) end end end local e = {} function e:onEvent(event) if event.id == 24 then volS.params.point = event.initiator:getPoint() world.searchObjects(2, volS, ifFound) trackWeapons() end end world.addEventHandler(e)

There has been a long standing behavior where getCategory returns the object category and not any sub-category within that object type. Its returning whether it is a unit, weapon, static object, base, etc. The workaround, especially if using weapons, is to use getDesc() and then check the weapon category and other info like missileCategory or guidanceType

AI won't accept the commands while they are late activated or uncontrolled. What you can do is modify the frequency that gets set in the group that spawns in. local gp = mist.getGroupTable("whatever") gp.frequency = 256 -- freqyncy set via editor is in this format because who cares about consistency mist.dynAdd(gp) Silence is a little more tricky but still doable by adding the task to the AI's task queue. See this page as an example. https://wiki.hoggitworld.com/view/DCS_exam_group_plane It gets tricky because the formatting of the table can be changed based on the tasks that are assigned on a given waypoint. Best to place an AI unit with the task, save the mission, then open that mission archive, then load the mission file into a text editor to get the formatting used. You can assign the frequency there too if you wanted.

DCS automatically erases a few libraries like io, lfs, and os, but you can re-enable that by manually editing Scripts/MissionScripting.lua. This is required for plenty of missions that have any sort of persistence built in. Time delays are done by putting what is needed into a function and scheduling it to run at a later time. local function myFunction() spawnGroup("gp1") end timer.scheduleFunction(myFunction, {}, timer.getTime() + 120)

Dissect what those functions are actually doing and re-purpose it for your own needs. Think of it like this, with that script you are telling it to iterate all blue vehicles for each zone. This means that it is getting the location of the same unit 4 different times and comparing it to each zone. Furthermore by your own rules only one unit has to be in the zone for it to be captured. That script doesn't know that, which means if may find the first unit in the zone on the first check, or it might find that unit on the last check, and anywhere in between. Point is it is probably checking units when it doesn't need to. local blueUnits = {} -- assumes list of unit objects. local zones = {{zone = 'Red City - 4'},{zone = 'Red City - 3'}, {zone = 'Red City - 2'}, {zone = 'Red City - 1'}, } --saved as tables so that you can save or set values associated with each zone. local function checkZones() local cZones = mist.utils.deepCopy(zones) local num = 0 for i = 1, #blueUnits do local unit = Unit.getByName(blueUnits[i]) if unit then local pos = unit:getPoint() for j = 1, #cZones do if not cZones[j].found then if unitInZone == true then -- whatever your code for checking it is, whether its a circle or polyzone -- set flag if needed cZones[j].found = true num = num + 1 end end end end if num == #cZones then -- once all zones have 1 unit then the loop can be broken out of break end end end Unfortunately we don't have a cargo unhook event which means you have to constantly check the position of the cargo objects to determine if it is in a zone. local dropZones = {"dz1", "dz2"} local crates = {"c1", "c2", "c3"} local rngGroups = {"g1", "g2"} for i = 1, #crates do local so = StaticObject.getByName(crates[i]) if so then local point = so:getPoint() for j = 1, #dropZones do if mist.utils.get2DDist(point, mist.DBs.zonesByName[dropZones[j]].point) < mist.DBs.zonesByName[dropZones[j]].radius then -- only works for circle zones local ng = mist.getGroupData(rngGroups[math.random(#rngGroups)] -- picks random from list local offset = {x = point.x - ng.units[1].x, y = point.z - ng.units[1].y} -- figures out the difference of where the group was placed at vs where it will be ng.units[1].x = point.x -- redfines start point X ng.units[1].y = point.z -- redefines start point y if #ng.units > 1 then for u = 2, #ng.units do --- offsets other units in the group ng.units[u].x = ng.units[u].x + offset.x ng.units[u].y = ng.units[u].y + offset.y end end ng.clone = true -- sets the group as a clone so it creates a fully new group. mist.dynAdd(ng) -- spawns a new group so:destroy() -- removes the crate crates[i] = nil -- removes the crate name from the list end end end end

1. Not sure, never used it in a MP mission. It is one of those things where crashes were more common, but a specific crash was never identified. Its possible that the issue has been inadvertently addressed. 2. Primary use cases are for training missions where you respawn dead units in the same location so that the dead wreck isn't clipping into the live unit. Cleanup of airfields in general to get rid of debris that may cause issues taxiing around. If someone decides to bomb a friendly airfield you can effectively undo the damage of the craters. 3. I suppose it depends. Larger search area means more time to process it and possibly more objects to cleanup. I haven't actually tested the limits of it that much so I have no idea if it scales as poorly as world.searchObjects does in certain circumstances. I know those that have used it typically just had an area of a few KM and ran the function around airbases for the sake of cleanup.

It is a map maker and AI taxi rules problem. Map maker because they decided to create those hangars and configured their size to be however large. AI taxi rules because the AI only have the 3d box of a given parking spot to decide whether or not they can park there and ignore any 3d collision meshes that they will run into on the way. There is a solution, though not the most obvious one. Which is also a bit of a mission editor oversight. With the landing task you can force AI to use specific parking spots. The landing, rearm, refueling task replaces that UI element with how long it takes to rearm. However the parking value still exists with the actual waypoint and group. A solution would be to place the waypoint as a landing waypoint, setup the desired parking values, then change the waypoint to the land, rearm, refuel waypoint task. You can then add waypoints as you desire. IIRC it is finicky if you select the parking spots for other waypoint and may reset the value. Alternatively it might be better to treat each take-off as its own flight and not using the land, rearm, refuel waypoint type. Tell AI to take-off and land at specific parking spots then respawn them via script or spawn in another flight to replace them.

Spread 4 maybe? In general the AI formation behavior is quite sub-par with all of the elevation changes they go through. Really with there was a way for them to do in place turns, but whatever.

Most difficult part would be to build a valid path for them to take through the canal. Ship AI is finicky when near terrain like that. They don't actually have AI to navigate around obstacles, which means they precisely follow the path set and if they think they will collide with the terrain they will just stop outright. Its a problem with larger ships like the giant cargo ship and aircraft carriers. Managed getting a frigate to make it through after a few attempts.

I did a thorough test on this. Usually no4 has the most extreme behaviors. Look for the more uniformity in their paths for the "best" at formation keeping behavior. https://imgur.com/a/TLFegLW

It is a DCS problem in general. The only workaround is something I wouldn't quite call a workaround, more of an exploit of the current logic by reusing existing units in the mission. Say you have a JF-17 placed in the miz file, you can use coalition.addGroup and re-use the unit and group names/ids. It could be halfway across the map from where it was placed, but to the game its still the same unit. The debrief screen might then know what that unit is.

The debriefing screen has never been great at dealing with anything spawned via scripting. It is simply a symptom of that longstanding problem. Initiator being the unique id, without other data for instance.

Static objects can block a given spawn point from being used if it is close enough the the spawn area. Here is an A-10 assigned to take-off from one parking spot, but the static object effectively blocks it, which results in the aircraft being spawned one parking spot over in the mission itself. Best to move the static objects away from where you want the aircraft to spawn at and gradually move them in until it moves the unit. Then you'll know you've gone to far.

Yeah it has been reported.

The AI take-off priority is pretty easy to figure out. For multiple groups the order is based on the taxi distance of the flight lead from the start of the runway. Then each group will taxi based on that order. For example in the screenshot below the top aircraft is closer to the runway, but has a longer taxi distance to get there. In this instance the aircraft with the blue path will taxi first. Additional wingmen add an extra rule, but it is still straight forward. Within a given flight the taxi order is always based on the flight member with it being 1, 2, 3, 4 regardless of location. The next flight will wait until the last wingman of the current flight begins to taxi and is closer to the runway. Using the screenshot again imagine if the blue path AI has a wingman at parking number 5, lets call it "blue 2". The red path AI will taxi almost at the same time as blue 2 because the path of blue 2 is still shorter than the red path AI, and it won't need to wait. It gets annoying if blue 2 is parked someplace further away from the flight lead. In one instance lets say blue 2 is at parking 120. The blue path flight lead will taxi, once it passes 120 then blue 2 will start to taxi, and then red path AI will taxi with little delay. Likewise if you put blue 2 way up in the north eastern corner of the base it will taxi at the same time as its flight lead, but the red path AI will wait until blue 2 is closer to the runway than itself. That said there are plenty of other nuances to AI taxiing behavior that are partly down to general AI rules and even how airbases themselves are setup. You can create a empty mission, slap some AI down, set the wind, and you can easily experiment with how unit placement impacts take-off order.

getRunways returns a table entry called "Name" that gives you the heading name. But it doesn't account for parallel runways. You should have enough data there to derive it via code if needed.

Think it is just the S-60 and KS-19. The value you are thinking of is the one below. Don't know the specifics but comparing it to other entries the "none" likely signifies that it can attack on its own, but may be less accurate or limited to its own sensors. The 2nd input likely refers to the type of dependence or what it provides. __LN.depends_on_unit = {{{"SON_9", 4}}, {{"none"}}}

Sadly no. Best you can try to create an explosion on the ship, but I don't have the math to get precise outcomes.

You have to make sure the markId is unique when you create it. The second input value is used as the id, and you have it being the same for both. You can use the mist.marker.add function to create it if you don't want to have to manage it yourself. local ref = trigger.misc.getZone("Novo") trigger.action.circleToAll(-1 , 1, ref.point , ref.radius , {1, 1, 1, 1} , {0, 0, 0, .2} , 1 , true) local ref = trigger.misc.getZone("Krymsk") trigger.action.circleToAll(-1 , 1, ref.point , ref.radius , {1, 1, 1, 1} , {0, 0, 0, .2} , 1 , true) You could pretty easily use world.getAirbases and the base capture event to draw the circles as needed.